Looks like this should work...
>From http://www.cs.cf.ac.uk/Dave/C/node27.html The following code fragment demonstrates a use of this to create a block of scratch storage in a program, at an address that the system chooses.: int fd; caddr_t result; if ((fd = open("/dev/zero", O_RDWR)) == -1) return ((caddr_t)-1); result = mmap(0, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); (void) close(fd); Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Richard Hipp [d...@sqlite.org] Sent: Thursday, March 08, 2012 10:35 AM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] SIGBUS error in case of disk full with WAL mode 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
