Hi Stephan,

Many thanks for your response, much appreciated...

May I ask what you suggest with the way I am using the sqlite3_busy_handler? 
What is the "normal approach"? I have tried to look at examples etc

p = sqlite3_malloc(256);
sqlite3_busy_handler(handle, &eventLoggerBusyHandler, p);
sqlite3_free(p);

Also, you mentioned the following "should fail"

sqlite3_exec(handle,"PRAGMA default_cache_size = 50;",0,0,0);

Should I rather take it out?

Thanks again for your comments, I will try re-work some of the code ;-)

Lynton

-----Original Message-----
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] 
On Behalf Of Stephan Beal
Sent: Tuesday, September 06, 2011 11:55 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] MemoryScape saying I have LEAKS in my SQLite code?

While i can't answer the question about the leaks, i can say...

On Tue, Sep 6, 2011 at 10:49 AM, Grice, Lynton (L)
<lynton.gr...@sasol.com>wrote:

> int queue_peekByTID(const char *tid, message *msg){ What is wrong with 
> my code above? Must I FREE the char*? Why would something say it was a 
> "leak"?
>

This technically isn't legal any more:

char *eventLogTable = "CREATE TABLE IF NOT EXISTS [log] ( "...

that should be const char *.

And NEVER free() a stack-allocated string.

I am also getting it complaining when I do a "sqlite3_finalize(stmt);"
>

If that's happening then it is likely that either your db is hosed,
sqlite3_prepare() failed, or you're finalize()ing twice. Your code above does 
not check the return value of prepare(), and there ARE reasons a
prepare() can fail which have nothing to do with the validity of the SQL you 
give it.



>        p = sqlite3_malloc(256);
>        sqlite3_busy_handler(handle, &eventLoggerBusyHandler, p);
>        sqlite3_free(p);
>

That almost certainly is not what you want to do. p will be passed to the busy 
handler, but it will be invalid because you free()d it. That same address might 
later be re-allocated to a different type of object, which would then 
(invalidly) be accessed by the busy handler. i.e. memory corruption (which 
might even be a source of reported leaks).

       sqlite3_exec(handle,"PRAGMA default_cache_size = 50;",0,0,0);
>

are you sure this cannot fail?

       rc = sqlite3_exec(handle,journalMode,0,0,0);
>        if(rc == OK){
>          rc = sqlite3_exec(handle,eventLogTable,0,0,0);
>          if(rc == OK){
>            rc = sqlite3_exec(handle,trigger,0,0,0);
>          }
>        }
>    }
>    return successFlag;
>

wouldn't it be simpler (and more accurate) to return rc instead of successFlag 
(which is not set properly, IMO, if journalMode, eventLogTable, or trigger fail 
to exec().

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
----------------------------------------------------------------------------
NOTICE: Please note that this eMail, and the contents thereof, 
is subject to the standard Sasol eMail legal notice which may be found at: 
http://www.sasol.com/legalnotices                                               
                                                           

If you cannot access the legal notice through the URL attached and you wish 
to receive a copy thereof please send an eMail to 
legalnot...@sasol.com
----------------------------------------------------------------------------
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to