On Apr 1, 2005, at 11:10 AM, Stephen C. Gilardi wrote:
For several months now, I've gotten similar errors when I run the test on my PowerBook G4. For me, the set of tests that fail is different from test run to test run, but they do seem to be concentrated in the "*ioerr" tests for the most part.

I've run the test several times on a G5 PowerMac and I have never seen the problem. I know at least some of the official Mac OS X testing for sqlite is done on a G5. That may explain why this hasn't been seen a lot by the development team.

I've enclosed the results of two test runs from today's cvs sources checked out into a new empty directory on my PowerBook G4. A similar run on a G5 PowerMac succeeded. In all cases, this is Mac OS X 10.3.8 with all current updates.

The intermittent nature of the failure suggests to me that it is some kind of timing-related problem. I'll be happy to work with anyone to try to debug this or test possible fixes.

This is actually due to a bug in SQLite's Makefile.in for the testfixture target. In particular, it recompiles most of the library and then links in a fashion such that many of the modules -- the .o files -- are effectively linked twice. Because they are linked twice and twolevel namespaces are enabled, the modules use of static variables becomes very, very confused. Effectively, you end up with two instances of a static variable with the different instances being used in different contexts, depending on which codepath is followed.


The fix is to NOT disable twolevel namespaces, but to fix SQLite's Makefile.in to not hoark the linking of the testfixture. Once this is fixed, all of the unit tests pass all of the time on Mac OS X. Having run said unit tests approximately 8 bazillion times as a part of my day job, I'm 100% confident that this is the case. ;-)

The good news is that this bug only affects the testfixture, not the library itself.

b.bum

Reply via email to