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] -----------------------------------------------------------------------------
