"Peter Weilbacher" <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Mar 2008 17:52:21 UTC, drh wrote:
> 
> > Any additional information you can send, such as the size of
> > the database file at the point of failure, or the exact line
> > on which the problem occurs, will be appreciated.  (I know the
> > bug report gives a line-number, but line numbers shift from
> > one amalgamation to another, and I don't know which amalgamation
> > you are using - I want the text of the line on which the problem
> > occurs.)
> 
> I didn't know there were different amalgamations, I just picked the 
> tarball from the SQLite download page...

Well, there is the one on the download page, obviously.  But
you might also have pulled a different version of SQLite from
the CVS tree and built the amalgamation yourself.  Many users
will sometimes pull down a standard amalgamation but add their
on private header comment to explain where the code came from -
thus throwing off the line numbering.  If you can tell me that
the amalgamation in the bug report is *exactly* the same as the
one on the download.html page, that is all I need to know.

> 
> Looking at the call stacks of the crashes that Shawn pointed to, they 
> seem to be different between Windows and MacOSX. On Linux it doesn't 
> happen.

I spent some time writing a whole bunch of new tests for the
Bitvec module in SQLite.  It is a new module, so it immediately
comes under suspicion.  But the module is used on *every* transaction
and millions of transactions are run by the SQLite test suite and
they all work perfectly on all platforms.  And the Bitvec module
has its own set of unit tests which also work perfectly.  And
yesterday, I wrote up a whole new set of Bitvec tests and they
all work perfectly too.  I also observe that all the Bitvec tests,
and indeed all SQLite tests, work perfectly and report no errors
when running under valgrind.

But I also observe that line 22783 is common between the two
failures.  I'll focus on writing new tests to further exercise
that line of code, and reanalyze the code looking for problems.
If you have additional failures, please send me stack traces,
as this might provide additional clues.

> 
> Windows has this at the top:
> 0     sqlite3BitvecSet           mozilla/db/sqlite3/src/sqlite3.c:22783   
> return sqlite3BitvecSet(p->u.apSub[bin], i);
> 1     sqlite3BitvecSet           mozilla/db/sqlite3/src/sqlite3.c:22800   if( 
> aiValues[j] ) rc |= sqlite3BitvecSet(p, aiValues[j]);
> 2     sqlite3PagerDontRollback   mozilla/db/sqlite3/src/sqlite3.c:27282   
> sqlite3BitvecSet(pPager->pInJournal, pPg->pgno);
> [etc.]
> 
> For MacOSX it is:
> 0     sqlite3BitvecSet    mozilla/db/sqlite3/src/sqlite3.c:22769   if( 
> p->iSize<=BITVEC_NBIT ){
> 1     sqlite3BitvecSet    mozilla/db/sqlite3/src/sqlite3.c:22783   return 
> sqlite3BitvecSet(p->u.apSub[bin], i);
> 2     allocateBtreePage   mozilla/db/sqlite3/src/sqlite3.c:27282   
> sqlite3BitvecSet(pPager->pInJournal, pPg->pgno);
> 
> I pasted the code from the lines pointed to by the line number for the 
> topmost entries, perhaps that helps.
> 

--
D. Richard Hipp <[EMAIL PROTECTED]>

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to