On Apr 2, 2010, at 4:23 PM, Kevin M. wrote: > Nope, somefunc isn't VFS related at all. In fact, that class only > makes one query itself and it calls the CMySQLWrapper class to > actually run the query and then grabs results from there. And the > method that makes the query would be the caller, not the callee in a > stack trace. Further, that method would not be called by the user > actions performed. Also, I recompiled the code, ran it again, > performed the same actions and got this stack trace:
I'm guessing your application has heap corruption. That would explain the weird stack locations down toward the bottom of the stack frame, and the fact that the same exact query works fine in sqlite3.exe. > > ntdll.dll!7c91b21a() > [Frames below may be incorrect and/or missing, no symbols loaded for > ntdll.dll] > ntdll.dll!7c90d7da() > msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=32641104, int > nhFlag=0, int nBlockUse=5752, const char * szFileName=0x00000004, > int nLine=2089816134) Line 268 + 0x15 bytes > msvcr80d.dll!_VEC_memzero(void * dst=0x00269148, int val=2527112, > int len=4936254) + 0x36 bytes > MyApp.exe!winMutexEnter(sqlite3_mutex * p=0x00268f88) Line 15621 > MyApp.exe!pager_open_journal(Pager * pPager=0x00000000) Line 35855 > + 0x5 bytes > MyApp.exe!sqlite3BtreeBeginTrans(Btree * p=0x00000000, int > wrflag=1) Line 40671 + 0x1c bytes > MyApp.exe!sqlite3VdbeExec(Vdbe * p=0x00000000) Line 55684 + 0x9 bytes > MyApp.exe!sqlite3Step(Vdbe * p=0x00000000) Line 51342 + 0x7 bytes > MyApp.exe!sqlite3_step(sqlite3_stmt * pStmt=0x002686b8) Line 51404 > + 0x7 bytes > MyApp.exe!sqlite3_exec(sqlite3 * db=0x002686b8, const char * > zSql=0x01f23520, int (void *, int, char * *, char * *)* > xCallback=0x00000000, void * pArg=0x00000000, char * * > pzErrMsg=0x00e7efe0) Line 11308 + 0x6 bytes > MyApp.exe! > CMySQLWrapper > ::Exec > (ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > > query="UPDATE tablename SET field=12345;") Line 1335 + 0x27 bytes > > There was no code changes, I just recompiled and ran things as > before. This is why I'm wondering if sqlite3_exec() has a bug. The > fact that sqlite3Step() gets passed a null pointer makes me wonder > if that is how it is going into the weeds. I'm just not sure how > sqlite3_step is calculating a null pointer for sqlite3Step(). > > I realized I put CMySQLWrapper in both stack traces given, but > should note that there's no MySQL in there, that was just a quick > random name choice to change the name from that of the real code. > > -- Kevin > > > > > ________________________________ > From: Pavel Ivanov <paiva...@gmail.com> > To: General Discussion of SQLite Database <sqlite-users@sqlite.org> > Sent: Fri, April 2, 2010 1:57:49 PM > Subject: Re: [sqlite] Possible bug in 3.6.23? > > What does CMyAppClass::somefunction() do? Is it your own VFS > implementation? > > > Pavel > > On Fri, Apr 2, 2010 at 1:06 PM, Kevin M. <athlo...@yahoo.com> wrote: >> I've had problems with update queries using sqlite 3.6.23 on >> Windows XP + Visual Studio 2005 and am wondering if it is a bug. >> sqlite seems to go off into the weeds when calling sqlite3_exec(). >> I've also had the same behavior when using sqlite3_prepare_v2() + >> sqlite3_step() + sqlite3_finalize() instead of sqlite3_exec(). The >> problem seems to be in sqlite3_step(). I can run the query by hand >> using sqlite3.exe on the database and the query is successful. >> >> I've changed the app name, class names and associated method names, >> table name and field name in the stack trace below, but otherwise >> everything is the same. The query is: >> >> UPDATE tablename SET field=12345; >> >> ntdll.dll!7c91b21a() >> [Frames below may be incorrect and/or missing, no symbols loaded >> for ntdll.dll] >> ntdll.dll!7c90d7da() >> msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=520, int nhFlag=0, >> int nBlockUse=7784, const char * szFileName=0x00000004, int >> nLine=2089816134) Line 268 + 0x15 bytes >> msvcr80d.dll!malloc(unsigned int nSize=2527560) Line 154 + 0x15 >> bytes >> MyApp.exe!CMyAppClass::somefunction() + 0x376 bytes >> MyApp.exe!writeJournalHdr(Pager * pPager=0x00000000) Line 32595 + >> 0x39 bytes >> MyApp.exe!pager_open_journal(Pager * pPager=0x00000000) Line 35855 >> + 0x5 bytes >> MyApp.exe!sqlite3PagerBegin(Pager * pPager=0x00000000, int >> exFlag=0, int subjInMemory=0) Line 35930 + 0x7 bytes >> MyApp.exe!sqlite3BtreeBeginTrans(Btree * p=0x00000000, int >> wrflag=1) Line 40671 + 0x1c bytes >> MyApp.exe!sqlite3VdbeExec(Vdbe * p=0x00000000) Line 55684 + 0x9 >> bytes >> MyApp.exe!sqlite3Step(Vdbe * p=0x00000000) Line 51342 + 0x7 bytes >> MyApp.exe!sqlite3_step(sqlite3_stmt * pStmt=0x002686b8) Line 51404 >> + 0x7 bytes >> MyApp.exe!sqlite3_exec(sqlite3 * db=0x002686b8, const char * >> zSql=0x01f2b798, int (void *, int, char * *, char * *)* >> xCallback=0x00000000, void * pArg=0x00000000, char * * >> pzErrMsg=0x00e7efe0) Line 11308 + 0x6 bytes >>> MyApp.exe! >>> CMySQLWrapper >>> ::Exec >>> (ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >>> > query="UPDATE tablename SET field=12345;") Line 1335 + 0x27 bytes >> >> >> Does this seem to be a bug? Is there other info that is needed? >> >> -- Kevin >> >> >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users D. Richard Hipp d...@hwaci.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
