Thank you for the response. So, how can I fix it? Can it have anything to do with sqlite3.lib? Is it a bug? Thank you in advance.
2007/12/12, Trevor Talbot <[EMAIL PROTECTED]>: > > On 12/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > "Trevor Talbot" <[EMAIL PROTECTED]> wrote: > > > > > test.exe: WinMain( ) + 71 > > > > sqlite3.dll: sqlite3_exec( ) + 154 > > > > sqlite3.dll: sqlite3_column_text( ) + 1A > > > > sqlite3.dll: sqlite3_data_count( ) + AC > > > > ntdll.dll: RtlEnterCriticalSection( ) + B > > > > Hmm, looks like a fault within SQLite's internal mutex handling. What > > > version of sqlite is this, and did you compile it yourself? I'm > > > wondering if it's not a compiler-related bug. > > > sqlite3_data_count() never touches a mutex. sqlite3_data_count() > > consists of 3 lines of code that extracts a value from the structure > > that is passed in as its only parameter. > > > > Furthermore, sqlite3_column_text() does not call sqlite3_data_count(), > > either directly or through intermediate subroutines. > > > > So I would be very suspicious about drawing conclusions from the > > stack trace above. > > Most of the Windows debugging tools will, in the absence of full > symbols, choose the closest public/exported symbol and print an > instruction offset from it. Not many optimizers are aggressive about > reordering functions, so usually code gets laid out in the order it > was written. That puts the mutex-related call not very far after > sqlite3_data_count(), like perhaps columnMem(). > > Still quite a bit of guesswork involved, but that's pretty much the > only way it's going to get from sqlite into RtlEnterCriticalSection(), > and it'll do as a starting point. > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > > ----------------------------------------------------------------------------- > >
