Re: [sqlite] MemoryScape saying I have LEAKS in my SQLite code?

2011-09-06 Thread Grice, Lynton (L)
Hi there,

Thanks for your comments, and I am passing NULL now to the busy handler..;-)

I also say on the SQLite site that the pragma " default_cache_size "  should 
not be used anymore 
(http://www.sqlite.org/pragma.html#pragma_default_cache_size )
("Do not use this pragma! This pragma is deprecated and exists for backwards 
compatibility only.")

Let me make some of the changes and see what MemoryScape says as well...I will 
let you know

Thanks

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 2:38 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] MemoryScape saying I have LEAKS in my SQLite code?

On Tue, Sep 6, 2011 at 2:28 PM, Grice, Lynton (L) <lynton.gr...@sasol.com>wrote:

> 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
>

Hi!

i don't use the busy handler, so i can't say, but i do know that it is NEVER 
valid to use a free()d pointer, and that's essentially what you've done here. 
If you don't want to pass any data to the busy handler then pass NULL as the 
final argument instead of a value which will be free()d immediately afterward 
sqlite3_busy_handler().


> p = sqlite3_malloc(256);
> sqlite3_busy_handler(handle, , p); 
> sqlite3_free(p);
>
> Also, you mentioned the following "should fail"


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

i didn't say it should/would, i implied that it _could_ by asking if you are 
_sure_ that it won't fail. If that fails, it might be useless to continue with 
the other queries, but the return code is not checked here.

Even "cannot fail" commands with perfect SQL syntax and well-defined semantics 
can fail because of external problems. e.g. out-of-memory or i/o error. Once 
you get one of these errors, it's generally not a good idea to continue using 
the db handle (i would argue, though there are those who could rightly argue 
otherwise).

--
- 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


Re: [sqlite] MemoryScape saying I have LEAKS in my SQLite code?

2011-09-06 Thread Stephan Beal
On Tue, Sep 6, 2011 at 2:28 PM, Grice, Lynton (L) wrote:

> 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
>

Hi!

i don't use the busy handler, so i can't say, but i do know that it is NEVER
valid to use a free()d pointer, and that's essentially what you've done
here. If you don't want to pass any data to the busy handler then pass NULL
as the final argument instead of a value which will be free()d immediately
afterward sqlite3_busy_handler().


> p = sqlite3_malloc(256);
> sqlite3_busy_handler(handle, , p);
> sqlite3_free(p);
>
> Also, you mentioned the following "should fail"


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

i didn't say it should/would, i implied that it _could_ by asking if you are
_sure_ that it won't fail. If that fails, it might be useless to continue
with the other queries, but the return code is not checked here.

Even "cannot fail" commands with perfect SQL syntax and well-defined
semantics can fail because of external problems. e.g. out-of-memory or i/o
error. Once you get one of these errors, it's generally not a good idea to
continue using the db handle (i would argue, though there are those who
could rightly argue otherwise).

-- 
- 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


Re: [sqlite] MemoryScape saying I have LEAKS in my SQLite code?

2011-09-06 Thread Grice, Lynton (L)
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, , 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, , 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


Re: [sqlite] MemoryScape saying I have LEAKS in my SQLite code?

2011-09-06 Thread Stephan Beal
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)
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, , 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


[sqlite] MemoryScape saying I have LEAKS in my SQLite code?

2011-09-06 Thread Grice, Lynton (L)
Hi there,

I am a huge fan of SQLite and have recently done some code that I am debugging 
with TotalView and MemoryScape (http://www.roguewave.com) - VERY VERY nice 
debugger, I have used GDB as well alot but Totalview is simply awesome

NOTE: C coding is NOT my day job ;-) So please bear with me

I am using MemoryScape (I suppose the same as Valgrind) to detect Memory leaks 
in my code.when I look at the leak detection I can see I have some small 
leaks in my SQLIte codeand would love someone to tell me how I can fix them?

For example MemoryScape complians about the following 2 lines below:

- idx = sqlite3_bind_parameter_index( stmt, ":tid" );
- rc = sqlite3_step(stmt);

Here is more of the code context

int queue_peekByTID(const char *tid, message *msg){
char *peekText = "SELECT * FROM queue WHERE tid = :tid;";
const char *value = NULL;
int idx;
int len;

sqlite3_prepare_v2(handle,peekText,-1,,0 );

idx = sqlite3_bind_parameter_index( stmt, ":tid" );
sqlite3_bind_text( stmt, idx, tid, -1, SQLITE_STATIC );

rc = sqlite3_step(stmt);
if(rc == SQLITE_ROW){


}

What is wrong with my code above? Must I FREE the char*? Why would something 
say it was a "leak"?

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

I another piece of code I am using SQLite to log certain events for meand 
complains about the following 3 lines below:

- rc = sqlite3_open_v2(eventLogName,, SQLITE_OPEN_READWRITE | 
SQLITE_OPEN_SHAREDCACHE | SQLITE_OPEN_CREATE, NULL);
- rc = sqlite3_exec(handle,journalMode,0,0,0);
- rc = sqlite3_exec(handle,trigger,0,0,0);

Here is the code context

int eventLogOpen(char *eventLogName, unsigned int eventLogRetentionPeriod){
char *eventLogTable = "CREATE TABLE IF NOT EXISTS [log] ( "
 "[idx] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, 
"
 "[timestamp] CHAR(25), "
 "[timestamp_secs] CHAR(10), "
 "[event_cat] CHAR(10), "
 "[event_tid] CHAR(50), "
 "[event_bus_ref] CHAR(50), "
 "[event_msg] TEXT);";

char trigger[2024];

if(eventLogRetentionPeriod > 0){
sprintf(trigger, "DROP TRIGGER IF EXISTS [log_retention]; "
 "CREATE TRIGGER [log_retention] "
  "AFTER INSERT ON log "
  "FOR EACH ROW BEGIN "
"DELETE FROM log "
"WHERE timestamp_secs < (strftime('%%s', 'now') - 
%i); "
  "END;", eventLogRetentionPeriod);
}

char *journalMode = "PRAGMA journal_mode=wal;";
int successFlag = ERROR;

rc = sqlite3_open_v2(eventLogName,, SQLITE_OPEN_READWRITE | 
SQLITE_OPEN_SHAREDCACHE | SQLITE_OPEN_CREATE, NULL);
if (rc == OK){
successFlag = OK;
p = sqlite3_malloc(256);
sqlite3_busy_handler(handle, , p);
sqlite3_free(p);
sqlite3_exec(handle,"PRAGMA default_cache_size = 50;",0,0,0);
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;
}

Is there anything I can do to prevent these "leaks"? Maybe I need to clean up 
using some other SQLite functions I am not aware of etc?

Thanks for the help ;-)

Lynton











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