assertion in cscvs WAS: [Gnu-arch-users] Re: cscvs canonical tree ?

[Parker, Ron]

(This originally only when to Charles Duffy.  Silly Outlook doesn't reply
properly by default.  I am just now posting it to the list with a few
spelling corrections.)

Actually I chased this one down when playing with cscvs on Cygwin.  That'll
cause brain damage way faster than huffing.  You're using an alpha tla for
Cygwin with a hacked PySQLite that can grok Posix and Windows paths.  Then
add an SQLite that partially bypasses Cygwin and directly uses Windows file
paths.  (See, there's shiny paint all over my face.  I completely expect to
be on the next episode of COPS.  ''This unfortunate fool believed he could
get away with doing serious work on Windows, but Sgt. Gates caught him in
the end.")

> From: Charles Duffy [mailto:address@hidden
> Sent: Thursday, February 26, 2004 4:38 PM

> On Thu, 2004-02-26 at 14:14, John Goerzen wrote:
> > On Thu, Feb 26, 2004 at 01:49:19PM -0600, Charles Duffy wrote:
> > > On Thu, 2004-02-26 at 13:17, John Goerzen wrote:
> > > > python: src/pager.c:1168: syncJournal: Assertion 
> `!pPager->noSync'
> > > > failed.
> > > > Aborted
> > > 
> > > Looks like a Python interpreter bug to me.

Nope.

> > Actually, there is no pager.c in Python.  Sqlite perhaps?

It is coming from SQLite.  What follows are fragments from two emails to the
SQLite list, including a response from D. Richard Hipp, the author.

> -----Original Message-----
> From: D. Richard Hipp [mailto:address@hidden
> Sent: Thursday, February 19, 2004 7:35 AM
> 
> Parker, Ron wrote:
> > I wasn't exactly sure of how to classify this to enter it 
> as an official
> > bug.  Also I using a combination of software that I am 
> certain is out of the
> > ordinary.  First I'll discuss the assertion, then my environment.
> > 
> > What I am seeing is the following message:
> > 
> >     assertion "!pPager->noSync" failed: file "src/pager.c", 
> line 1168
> > 
> 
> The only way I've found to reproduce this is to do a
> 
>     PRAGMA synchronous=off
> 
> inside of a transaction.  OK, that's a bug.  I'll fix it.
> But in the meantime, your work-around is simple:  recompile
> with -DNDEBUG=1.  That will disable all the asserts.  (The
> particular assertion failure you are hitting appears to be
> completely benign.)  This fix, by the way, also has the
> nice benefit of making the library run 2x faster.
> -- 
> D. Richard Hipp -- address@hidden -- 704.948.4565
> 

My response after checking this out:

> From: Parker, Ron [mailto:address@hidden
> Sent: Thursday, February 19, 2004 3:44 PM

> Glad to know it is safe to ignore this one.  I'm somewhat of 
> an assert freak
> and hesitate to turn them off in someone else's code when I am doing
> something out of the ordinary.  That said, manually adding 
> -DNDEBUG=1 to the
> TCC flags in Makefile did the trick.  
> 
> I don't know if this is of any help to you are not, but as it 
> turns out,
> this assertion was being triggered right at the end of the 
> process that
> created the database.  When I compared my logs from the 
> failed run and from
> the NDEBUG run, they were identical except for the assertion. 
>  Also the
> NDEBUG run created a valid SQLite database.  The one that 
> asserted produced
> a corrupted database/journal combination.

So, your temporary solution is to rebuild SQLite with -DNDEBUG=1 added to
the TCC flags in the Makefile.