RE: [sqlite] sqlite testing with Boundschecker
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Sunday, July 01, 2007 11:11 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] sqlite testing with Boundschecker > > "Damian Slee" <[EMAIL PROTECTED]> wrote: > > > > I have done some testing with 3.2 and now 3.4, visual studio2003 and > > boundschecker (and XP). > > Thank you for the report. > > I have analyzed the errors reported by boundschecker and they > all appear to be false postives. The SQLite 3.4.0 code base > is correct in all cases and boundchecker is complaining about > problems that do not exist. > > The following is typical: > > > > > Dangling Pointer: Pointer 0x010D9250, allocated by HeapAlloc, has > already > > been freed. > > > > Vdbe.c sqlite3VdbeExec Line 469 > > > > if( p->magic!=VDBE_MAGIC_RUN ) return SQLITE_MISUSE; > > assert( db->magic==SQLITE_MAGIC_BUSY ); > > [pTos = p->pTos;] > > if( p->rc==SQLITE_NOMEM ){ > > > > There are two pointers on the offending line: "p" and "pTos". The > p pointer appears to be valid. Otherwise, the "return SQLITE_MISUSE" > two lines above would have be taken. Or at worst, the dereference > of p two lines above should have triggered a similar error. So > apparently boundschecker is upset because SQLite is merely making > a copy pointer to previously freed memory. There really is no > harm in this. Nothing bad can happen unless the program actually > tries to dereference the pointer - which it never does. BoundsChecker is pedantically correct: code which reads the value of such an indeterminate pointer has undefined behavior according to the C standard. Note that I do mean reading the value of the pointer, not dereferencing it (which is more obviously invalid). As for whether it's worth setting the pointer to null after the memory to which it pointed is freed, that's subjective. -- James - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite testing with Boundschecker
> So apparently boundschecker is upset because SQLite is merely making > a copy pointer to previously freed memory. There really is no harm > in this. Nothing bad can happen unless the program actually tries > to dereference the pointer - which it never does. I don't think GCC makes this guarantee. The standard certainly doesnt require this; copying a pointer value after the object it points to has been freed results in undefined behavior. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite testing with Boundschecker
"Damian Slee" <[EMAIL PROTECTED]> wrote: > > I have done some testing with 3.2 and now 3.4, visual studio2003 and > boundschecker (and XP). Thank you for the report. I have analyzed the errors reported by boundschecker and they all appear to be false postives. The SQLite 3.4.0 code base is correct in all cases and boundchecker is complaining about problems that do not exist. The following is typical: > > Dangling Pointer: Pointer 0x010D9250, allocated by HeapAlloc, has already > been freed. > > Vdbe.c sqlite3VdbeExec Line 469 > > if( p->magic!=VDBE_MAGIC_RUN ) return SQLITE_MISUSE; > assert( db->magic==SQLITE_MAGIC_BUSY ); > [pTos = p->pTos;] > if( p->rc==SQLITE_NOMEM ){ > There are two pointers on the offending line: "p" and "pTos". The p pointer appears to be valid. Otherwise, the "return SQLITE_MISUSE" two lines above would have be taken. Or at worst, the dereference of p two lines above should have triggered a similar error. So apparently boundschecker is upset because SQLite is merely making a copy pointer to previously freed memory. There really is no harm in this. Nothing bad can happen unless the program actually tries to dereference the pointer - which it never does. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] sqlite testing with Boundschecker
Hi, I have done some testing with 3.2 and now 3.4, visual studio2003 and boundschecker (and XP). I get a few reported errors when I simply do the .dump command with no db. Happens on other times with a db, this is easier. Line numbers are from the downloaded 3.4.0 source. I don’t really know how the vdbe works, so not sure how to start on solving the write overrun one… Thanks, damian Vdbeaux.c sqlite3VdbeChangeP3 line 534 Memory block at address void* _Src = 0x0012C92C in argument 2 in memcpy is too small, should be 17, was 16. if( pKeyInfo ){ unsigned char *aSortOrder; memcpy(pKeyInfo, zP3, nByte); aSortOrder = pKeyInfo->aSortOrder; Write Overrun: Memory write to 0x010D8A88 (2) overruns destination block 0x010D89F8 (60) allocated by HeapAlloc. Vdbe.c, sqlite3VdbeExec, Line 701. This occurs when running sqlite3.exe with no db, then executing .dump, then second breakpoint on the pTos->flags line invokes this boundschecker error. case OP_Integer: { pTos++; pTos->flags = MEM_Int; pTos->u.i = pOp->p1; break; } Resource Leak Exiting Program: Handle 0x0014 allocated by TlsAlloc. Os_win.c line 1730 if( !keyInit ){ sqlite3OsEnterMutex(); if( !keyInit ){ key = TlsAlloc(); if( key==0x ){ sqlite3OsLeaveMutex(); return 0; } Dangling Pointer: Pointer 0x010D9250, allocated by HeapAlloc, has already been freed. Vdbe.c sqlite3VdbeExec Line 469 if( p->magic!=VDBE_MAGIC_RUN ) return SQLITE_MISUSE; assert( db->magic==SQLITE_MAGIC_BUSY ); pTos = p->pTos; if( p->rc==SQLITE_NOMEM ){ Pointer Error: Pointer 0x010DA9F0, used as an argument, is out of range; no longer within block 0x010DAA30 (204), allocated by malloc. Vdbeaux.c, sqlite3VdbeMakeReady line 889 for(n=0; nnMem; n++){ p->aMem[n].flags = MEM_Null; } p->pTos = &p->aStack[-1]; p->pc = -1; p->rc = SQLITE_OK; similar error Cleanup, line 967 static void Cleanup(Vdbe *p){ int i; if( p->aStack ){ releaseMemArray(p->aStack, 1 + (p->pTos - p->aStack)); p->pTos = &p->aStack[-1]; } closeAllCursors(p); Similar error vdbe.c sqlite3VdbeExec, line2681 sqlite3VdbeMemIntegerify(pTos); iDb = pTos->u.i; assert( (pTos->flags & MEM_Dyn)==0 ); pTos--; assert( iDb>=0 && iDbnDb ); Unrelated Pointer: Comparing two unrelated pointers 0x010D8A30 and 0x010D8A70. Pointers are not within the same buffer. Vdbe.c sqlite3VdbeExec line 983 static void Cleanup(Vdbe *p){ int i; if( p->aStack ){ releaseMemArray(p->aStack, 1 + (p->pTos - p->aStack)); p->pTos = &p->aStack[-1]; } Unrelated Pointer: Comparing two unrelated pointers 0x010DAD10 and 0x010DACD0. Pointers are not within the same buffer. Vdbe.c sqlite3VdbeExec – line 983 pFirstColumn = &pTos[0-pOp->p1]; for(pMem = p->aStack; pMemaStack ){ releaseMemArray(p->aStack, 1 + (p->pTos - p->aStack)); p->pTos = &p->aStack[-1]; } Unrelated Pointer: Comparing two unrelated pointers 0x010DAD10 and 0x010DACD0. Pointers are not within the same buffer. Vdbe.c sqlite3VdbeExec line 983 pFirstColumn = &pTos[0-pOp->p1]; for(pMem = p->aStack; pMem