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.

Thanks very much for diagnosing the problem.

I took a look at the Makefile and I see that "libtool" is used for most of the compilation and linking, but for testfixture, some compilation is done without it. I can see that leading to the bad behavior you described.

It seems like one solution would be to build the TESTSRC files using libtool as well. I'm gathering that (at least for the shared library case) this would cause them to be linked them using the "-flat_namespace" option.

I don't currently know enough about Makefiles to know how to build .o files from .c files differently for different targets. We would need, for example, two .o files for btree.c depending on whether or not SQLITE_TEST is defined. Perhaps the "sqlite" library and a new "sqlitetest" library could have different subdirectories for their component object files.

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. ;-)

I'd like to be able to run the tests successfully as well. Would it be possible for you to send me a working Makefile.in to use as an example?


I'd be happy to study it until I understand it and then write up the changes as a bug report to sqlite.org if you don't want to do that for some reason.

I'd appreciate any help.

Thanks,

--Steve

On Apr 1, 2005, at 2:54 PM, [EMAIL PROTECTED] wrote:

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