[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_1111789746/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] -----------------------------------------------------------------------------
