>> Correct. Also, it only happens when apsw is compiled with -g. > > The amalgamation is being used when you compiled APSW. When you compile > APSW with debug and the amalgamation, two things happen. Firstly assertions > are turned on in both APSW and SQLite. > ... > Secondly it enables SQLITE_DEBUG.
Roger, '-g' flag doesn't necessarily mean SQLITE_DEBUG turned on and doesn't mean all debugging stuff turned on. This flag (if we're talking about gcc) only means that debugging symbols should be included into final binary. When all debugging stuff is turned on then most probably optimization is turned off and 'volatile' wouldn't mean much in this case. Apparently in Nikolaus's case -g also triggers different kind of optimization which causes the error. >> Yeah, I'm around. I don't know what an "exact disassembly" is or how to >> provide one, but if someone tells me what to do then I'm most likely >> willing to do it. Nikolaus, you can do it like this: > gdb your_application (gdb) disassemble pthreadMutexEnter I made that for my application and see this: Dump of assembler code for function pthreadMutexEnter: 0x00000000005d60c0 <pthreadMutexEnter+0>: push %rbx 0x00000000005d60c1 <pthreadMutexEnter+1>: mov %rdi,%rbx 0x00000000005d60c4 <pthreadMutexEnter+4>: callq 0x472750 <pthread_mutex_l...@plt> 0x00000000005d60c9 <pthreadMutexEnter+9>: callq 0x471dc0 <pthread_s...@plt> 0x00000000005d60ce <pthreadMutexEnter+14>: incl 0x2c(%rbx) 0x00000000005d60d1 <pthreadMutexEnter+17>: mov %rax,0x30(%rbx) 0x00000000005d60d5 <pthreadMutexEnter+21>: pop %rbx 0x00000000005d60d6 <pthreadMutexEnter+22>: retq End of assembler dump. Obviously optimizer switched order of changing owner and nRef. So my application is also prone to this kind of failure. Fortunately for me I use my own implementation of cache... Pavel On Thu, May 13, 2010 at 1:56 PM, Roger Binns <rog...@rogerbinns.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/13/2010 06:43 AM, Nikolaus Rath wrote: >> Yeah, I'm around. I don't know what an "exact disassembly" is or how to >> provide one, but if someone tells me what to do then I'm most likely >> willing to do it. > > We can test the hypothesis very easily. Find line 15472 in the > amalgamation. A few lines up there should be #ifdef SQLITE_MUTEX_PTHREADS. > Put "volatile" as a prefix for the nRef and owner declarations. > > volatile int nRef; /* Number of entrances */ > volatile pthread_t owner; /* Thread that is within this mutex */ > > Please let us know the results and I'll update the ticket. > >> Correct. Also, it only happens when apsw is compiled with -g. > > The amalgamation is being used when you compiled APSW. When you compile > APSW with debug and the amalgamation, two things happen. Firstly assertions > are turned on in both APSW and SQLite. These are put in by the programmers > and verify that the internal state matches expectations (for example that a > particular code path will not be called unless a flag is set, or that when > one internal routine calls another it will never pass zero as a parameter). > This is very helpful when developing new code, major modifications to > existing code and running the test suites. > > Secondly it enables SQLITE_DEBUG. This enables a lot of extra code in > SQLite doing such things as enabling detailed tracing, and more heavyweight > checking which includes mutexes. This is an additional layer of helpfulness > for developing the code and test suites. The existing mutex checking debug > code allows the compiler more scope for optimisation but will give the wrong > answer if threading happens at "unlucky" points. volatile prevents the > compiler from making those optimisations. > > When using assertions and SQLITE_DEBUG you should see at least a 30% > performance hit because of all the extra checking. > > There is no reason to enable the assertions or SQLITE_DEBUG unless you > strongly believe there is an uncaught bug in the code (especially internal > routines calling other internal routines) that hasn't been caught by > existing test suites. Those kind of bugs are far easier to detect by source > code review. > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvsPUkACgkQmOOfHg372QTI9wCfRgBNgU4nMwLaQa3uJKxZ3Ffs > /XYAoJgxkSl7nfEoTEG1m9Mzj4sDLazI > =sOFw > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
