On Mar 2, 2010, at 6:54 PM, Jonathan Kew wrote:
> I've run into what appears to be a small bug in this function (from
> sqlite3.c, v 3.6.22). Suggested patch:
>
> diff --git a/sqlite3.c b/sqlite3.c
> --- a/sqlite3.c
> +++ b/sqlite3.c
> @@ -16938,17 +16938,17 @@ SQLITE_PRIVATE void sqlite3VXPrintf(
> int i, j, k, n, isnull;
> int needQuote;
> char ch;
> char q = ((xtype==etSQLESCAPE3)?'"':'\''); /* Quote
> character */
> char *escarg = va_arg(ap,char*);
> isnull = escarg==0;
> if( isnull ) escarg = (xtype==etSQLESCAPE2 ? "NULL" :
> "(NULL)");
> k = precision;
> - for(i=n=0; (ch=escarg[i])!=0 && k!=0; i++, k--){
> + for(i=n=0; k!=0 && (ch=escarg[i])!=0; i++, k--){
> if( ch==q ) n++;
> }
> needQuote = !isnull && xtype==etSQLESCAPE2;
> n += i + 1 + needQuote*2;
> if( n>etBUFSIZE ){
> bufpt = zExtra = sqlite3Malloc( n );
> if( bufpt==0 ){
> pAccum->mallocFailed = 1;
>
> (The original code is found in src/printf.c.)
>
> The issue here is that when k reaches zero, the access to escarg[i]
> may try to look one byte beyond the end of the allocated buffer; to
> avoid this, simply reverse the order of the tests so that k is
> checked for non-zero first.
>
> The error is normally harmless, testing a "random" byte and then
> exiting the loop anyway because of the value of k, but it can cause
> a bus error in the (extremely rare) event that the buffer is
> allocated exactly at the end of a virtual memory page, and the
> following page is unallocated. (This was encountered when running
> under Guard Malloc.)
Shouldn't escarg[] contain a nul-terminated string?
How did you provoke the error under Guard Malloc? Do you
have a stack trace? I'm thinking the error might be caused
by some bug in the caller.
Dan.
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
