Re: [sqlite] strange issue with broken links/hung processes in transaction
On Tue, 31 Oct 2006 [EMAIL PROTECTED] wrote: I suspect that the /var/tmp file is unrelated to your mmap/munmap problem. When SQLite needs a temporary file on Unix, it creates the file, opens it, then calls unlink(). Unix removes the inode for the file from its directory immediately so that the file cannot be opened again by another process. But it does not delete the file until the file descriptor is closed. This is how you make temporary files in Unix that automatically disappear when they are closed. right - that makes sense then... SQLite never calls mmap() or munmap() - at least not directly. Those routines might be called in your implementation of malloc() or as part of open()/read()/write(). But if so, that is an implementation specific thing. hmmm. most likey malloc - also, this kernel uses mmap to read in binaries and the specific amount of memory being asked for is quite large. in any case, i'll work on the assumption that sqlite is not at fault. thanks very much for the fast reply - and for a fantastic product. btw. this is what my software does with it http://www.linuxjournal.com/article/7922 cheers. -a -- my religion is very simple. my religion is kindness. -- the dalai lama - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] strange issue with broken links/hung processes in transaction
[EMAIL PROTECTED] wrote: > i have some code which uses sqlite heavily. every so often a command using > with hang indefinitely, running an strace on the code shows it to be stuck in > a loop doing > > >munmap addr1 >mmap #=> addr1 >munmap addr2 >mmap #=> addr1 >munmap addr1 >... >... >repeat forever... > > checking out the /proc filesystem for the process shows this oddity > >[EMAIL PROTECTED] 20793]$ ls fd >0 1 2 3 4 > >[EMAIL PROTECTED] 20793]$ file fd/* >fd/0: symbolic link to /dev/pts/3 >fd/1: symbolic link to /dev/pts/3 >fd/2: symbolic link to /dev/pts/3 >fd/3: symbolic link to > /tmp/_dmsp_reference_bin_rq_20793_609295232_789746/db >fd/4: broken symbolic link to /var/tmp/sqlite_dZtkItUXB3ppxor (deleted) > I suspect that the /var/tmp file is unrelated to your mmap/munmap problem. When SQLite needs a temporary file on Unix, it creates the file, opens it, then calls unlink(). Unix removes the inode for the file from its directory immediately so that the file cannot be opened again by another process. But it does not delete the file until the file descriptor is closed. This is how you make temporary files in Unix that automatically disappear when they are closed. SQLite never calls mmap() or munmap() - at least not directly. Those routines might be called in your implementation of malloc() or as part of open()/read()/write(). But if so, that is an implementation specific thing. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] strange issue with broken links/hung processes in transaction
i have some code which uses sqlite heavily. every so often a command using with hang indefinitely, running an strace on the code shows it to be stuck in a loop doing munmap addr1 mmap #=> addr1 munmap addr2 mmap #=> addr1 munmap addr1 ... ... repeat forever... checking out the /proc filesystem for the process shows this oddity [EMAIL PROTECTED] 20793]$ ls fd 0 1 2 3 4 [EMAIL PROTECTED] 20793]$ file fd/* fd/0: symbolic link to /dev/pts/3 fd/1: symbolic link to /dev/pts/3 fd/2: symbolic link to /dev/pts/3 fd/3: symbolic link to /tmp/_dmsp_reference_bin_rq_20793_609295232_789746/db fd/4: broken symbolic link to /var/tmp/sqlite_dZtkItUXB3ppxor (deleted) and, indeed, the /var//tmp file does not exist. i assume this file is the backing store sqlite uses for implementing transactions: it's certainly not created by my code. now, this is happening on a compute node with __zero__ other userland process running so i'm quite sure no other process is removing the file. also, disabling tmpwatch has no effect on the problem, which is both transient and infrequent. so - has anyone every seen this before? any thoughts on how to proceed? details: jib:~ > cat /etc/redhat-release Red Hat Enterprise Linux WS release 3 (Taroon Update 8) jib:~ > uname -srm Linux 2.4.21-47.0.1.ELsmp i686 jib:~ > sqlite -version 2.8.15 kind regards. -a -- my religion is very simple. my religion is kindness. -- the dalai lama - To unsubscribe, send email to [EMAIL PROTECTED] -
