Re: [sqlite] MemoryScape saying I have LEAKS in my SQLite code?
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?
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?
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?
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?
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