> Question: Does anybody know of a better way to get memory shared among > processes other than to create a fake file and mmap() it? Are there some > magic options to mmap() (perhaps Linux-only options) that prevent it from > actually writing to disk?
Why don't you use shm_open() instead of a real file? I'm not sure though how it behaves with chroot jail. Pavel On Thu, Mar 8, 2012 at 11:35 AM, Richard Hipp <d...@sqlite.org> wrote: > On Thu, Mar 8, 2012 at 10:58 AM, Yongiljang <yongilj...@gmail.com> wrote: > >> Dear all, >> I'm an android developer in charge of sqlite database. >> >> Some days ago, I'd got a SIGBUS error from sqlite when there is no space >> in current partition and WAL journal mode is used. >> This error was occurred from memset function in libc that was called by >> libsqlite and debugging information shows shm file was related to this >> issue. >> >> Following sequence shows how to generate this error. >> >> 1) Make disk full >> 2) Reboot device - wal and shm files are remained in some applications >> folder >> 3) Do 1) ~ 2) until free space remained under 32KB >> 4) SIGBUS error is occurred randomly >> >> I'd tried to solve this problem and guessed following scenario. >> >> 1) shm file is truncated to zero size by calling robust_truncate function >> when a new connection is opened in unixOpenSharedMemory >> 2) shm file is extended to 32KB by calling robust_truncate function in >> unixShmMap >> 3) mmap function is called with 32KB length >> >> In my guess, problem is occurred from robust_truncate or mmap functions, >> because of they didn't returned error code whether shm file is extended to >> 32KB or not on disk full status. >> robust_truncate and mmap may caused illegal memset operation because of >> shm file actually doesn't have 32KB size, it may less than 32KB. >> Interesting point is when I tested it with above scenario, there was a shm >> file that has 32KB size. >> It is impossible because of there was no space to make 32KB sized file in >> current partiton. >> > > We do not want to really make a file. The purpose of the -shm file is > merely to give a name to a block of memory that various processes accessing > the database can share between themselves using mmap(). Ideally, the > content of the -shm file remains the OS page cache and is never written to > disk. > > Can you please try this experiment for us: Beginning with a standard > SQLite build (without your patches) recompile using > -DSQLITE_SHM_DIRECTORY="/dev/shm". That option will cause the shared > memory file to be created in the /dev/shm directory rather than in the same > directory as the database. Since /dev/shm is not backed by disk (or flash) > the problem should be solved. > > FWIW: We looked at always putting the -shm files in a special directory > like this when we were first designing WAL. But we noticed that design > fails if two programs in different chroot jails try to access the database > at the same time, and so we switched to the current design of using the > -shm file in the same directory as the database. > > Question: Does anybody know of a better way to get memory shared among > processes other than to create a fake file and mmap() it? Are there some > magic options to mmap() (perhaps Linux-only options) that prevent it from > actually writing to disk? > > >> >> Whatever, I'd changed unixOpenSharedMemory to solve it. >> >> 1) make a shm file and write null data until 32KB if this file doesn't >> exists >> - return SQLITE_FULL error when write operation is failed >> 2) write null data until 32KB if this file exists and got write lock >> instead of calling truncate function to shrink shm file to zero size >> - return same error code when it failed >> >> By changed source, I could solve this problem. >> Sqlite returns SQLITE_FULL errors only without SIGBUS core dump. >> >> However, this instant code changing may not be a good solution. >> I wish to get better comment or source patches from here. >> >> Thank you for reading this including my poor english. :) >> >> Best wishes, >> Jang. >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > > > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
