On 4 December 2012, Paul Menzel wrote:
After doing `apt-get source sqlite3` and building it myself with
`debuild -b -us -uc`, I have the source file `sqlite3.c` and I am able
to look at the code statements.
> The backtrace from the core dump file is the following.
>
> Thread 1 (Thread 0x8acf1b70 (LWP 15522)):
> #0 0xb69bafe3 in pcache1Fetch (p=0xb8effb00, iKey=35985,
createFlag=2) at sqlite3.c:36093
> h = 1169
> nPinned = <optimized out>
> pCache = 0xb8effb00
> pGroup = 0xb8effb30
> pPage = 0xbf8ab0e8
The following code caused the segmentation fault.
Paul, I offer this to help you get your problem solved sooner, not
as criticism or complaint.
Earlier in this thread, Richard Hipp wrote:
Just because SQLite appears in a stack trace does not mean that SQLite is
at fault here. In fact, far more often than not, when SQLite appearing in
a stack trace it means that some other unrelated component of the
application has corrupted the heap and SQLite just happened to be the
unlucky subsystem to trip over that corruption.
If you can generate some evidence that SQLite is malfunctioning, we will be
happy to look into the situation for you, and perhaps open a ticket. But,
unfortunately, a single unreproducible segfault with a stacktrace that
includes SQLite routines does not constitute evidence of an SQLite
malfunction.
What you have supplied is evidence that SQLite either has a bug that your
code has exposed or its correct operation is subject to the various forms
of the "undefined behavior" that typically result from stray memory
overwrites by other code. There is no way, given the data you provide,
to distinguish between these cases, and it is a fool's errand to attempt
such an effort. The SQLite developers have better uses for their time
than to try to improve the codebase in response to allegations that it
might have a bug because its code exhibits the same vulnerability to
other code that every human-created C/C++ program must have.
To provide the most useful evidence of a SQLite bug, you need to create
some SQL that will crash the SQLite shell, or which will crash a C
program that is so simple that its correctness is apparent from some
reasonably small effort.
In all likelihood, you will be unable to create such a reproduction
scenario, and that should encourage you to start using a debug heap
or sophisticated tools such as Purify to discover where your code
has a stray memory write occurring.
Best regards,
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
