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

Reply via email to