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



I cannot reproduce the problem, either on CVS HEAD or on 3.0.8. My system is linux with gcc 3.2.

Note that when SQLite is compiled with -DSQLITE_TEST=1, it uses
a modified malloc() that inserts garbage prior to returning the
allocation, puts guard words before and after the allocation,
and overwrite the entire buffer after free().  Other debugging
malloc implementations (perhaps the one above) do more, but
this suffices to catch the common cases.  Nothing is found this
way.


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.

The -DSQLITE_TEST=1 option is designed to catch this stuff and it usually does.


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.


Not necessarily. There are a few places in the code where a pointer is made to point before an allocation because we know that the pointer will be used as an array with a non-zero index. I'll try to find time to look into this instance later tonight and see if this is one of those places.

The best way to get this fixed is to figure out how I can
reproduce it.  I'll try using the rigged malloc above if I get
a chance tonight.  Maybe that will help.



--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565



Reply via email to