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