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 = >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 = >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 = >aStack[-1];
}
Unrelated Pointer: Comparing two unrelated pointers 0x010DAD10 and
0x010DACD0. Pointers are not within the same buffer.
Vdbe.c sqlite3VdbeExec – line 983
pFirstColumn = [0-pOp->p1];
for(pMem = p->aStack; pMemaStack ){
releaseMemArray(p->aStack, 1 + (p->pTos - p->aStack));
p->pTos = >aStack[-1];
}
Unrelated Pointer: Comparing two unrelated pointers 0x010DAD10 and
0x010DACD0. Pointers are not within the same buffer.
Vdbe.c sqlite3VdbeExec line 983
pFirstColumn = [0-pOp->p1];
for(pMem = p->aStack; pMem
