On Thu, Jan 06, 2005 at 12:25:18PM -0800, Ted Unangst wrote: > D. Richard Hipp wrote: > >> > > > >Provice specific SQL that causes a problem. The same btree code > >has been in use for ages and there are many tests that do what > >you describe above. You are the first person to ever see this > >problem. Also say what OS and compiler you are using. > > sql below (it's fairly long). We're using FreeBSD 4.10 with gcc version > 2.95.4 20020320 [FreeBSD]. > > The primary difference is that we are using an unusually sensitive > malloc implementation. > http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/stdlib/malloc.c?rev=1.70 > > While it is certainly possible a bug remains in the malloc code, I don't > think that's the problem (it just means sqlite only crashes with this > malloc). For many malloc implementations, a minor buffer underflow is > harmless and hard to detect. > > Adding the assertion that pCell is within the memory region allocated to > apCell is correct is it not? It should not be 4 bytes before. If > that's wrong, I will go back to debugging this on my own. > > ok, mailing list doesn't like long messages. you can get the sql at > http://www.coverity.com/sqlcmds
my environment is OpenBSD/i386, sqlite 3.0.8 compiled with gcc 3.3.5. sqlite does pass all the regression tests with no malloc options, but with the following options enabled: A ``Abort''. malloc() will coredump the process, rather than tol- erate failure. This is a very handy debugging aid, since the core file will represent the time of failure, rather than when the null pointer was accessed. F ``Freeguard''. Enable use after free protection. Unused pages on the freelist are read and write protected to cause a segmenta- tion fault upon access. G ``Guard''. Enable guard pages and chunk randomization. Each page size or larger allocation is followed by a guard page that will cause a segmentation fault upon any access. Smaller than page size chunks are returned in a random order. J ``Junk''. Fill some junk into the area allocated. Currently junk is bytes of 0xd0; this is pronounced ``Duh''. :-) sqlite crashes on (at least) the trans-7.1 test. these options have caught real bugs before: http://uqm.stack.nl/cgi-bin/bugs/show_bug.cgi?id=649 http://cvs.sourceforge.net/viewcvs.py/sc2/sc2/src/sc2code/libs/uio/hashtable.c