|
Re: sqlite_free_table bug??: msg#00123db.sqlite.general
Ben: Thanks for clearing that up for me. That just shows how much better an experienced coder as compare to an elementrary co-op student like me =). I guess it will take some time before getting up to your level. Colin ben.carlyle-LNVqYbe/PQpWk0Htik3J/w@xxxxxxxxxxxxxxxx wrote: > > Colin, > > It's not possible to change the pointer back to null, nor is advisable. > It's not possible because you only pass a copy of the pointer into > sqlite_free_table. You don't pass in the address to the pointer yourself, > therefore the function couldn't possibly change your copy of the pointer. > It can only make changes to things your pointer points to. That's why it's > called a pointer :) > It's not advisable because that's not the way standard free() works. The > C-language free() function takes a pointer and returns the space allocated > at the other end to the memory allocation system. This is exactly what > sqlite_free_table does. Where there is a standard paradigm built into a > language, especially where it has to do with something so important as > memory allocation, it should be followed in every relevant detail. > > This is elementary C. > > If you're programming C++ you'll notice that delete doesn't change your > pointer either. If you want to be able to test whether a pointer is valid > or not, then after a delete, free, or sqlite_free_table you must set the > pointer back to null. You can change your FreeTable function to the > following: > > > void FreeTable( void ) { > > sqlite_free_table(result); > > result = 0; > > } > > Unfortunately this code breaks another basic design paradigm that you'd be > well advised to follow. That paradigm is "whoever allocates the memory > should ultumately be the one who cleans it up". You might be better off > writing your code like this: > > int foo(void) > { > char **result; > char *zErrMsg; > int rc; > int nrow, ncolumn; > rc = sqlite_get_table(db, "select * from abc", &nrow, &ncolumn, > &zErrMsg); > > if (rc == SQLITE_OK) > { > /* Do processing on the result here */ > sqlite_free_table(result); > } > else > { > if (zErrMsg) > { > printf("Warning: Error in foo() %s\n", zErrMsg); > free(zErrMsg); > } > } > > return rc; > } > > While your code avoids a continuous leak by freeing the last result before > allocating a new one, and while it could be modified with the result = 0 > line to avoid trying to free memory multiple times, you have still > allocated memory that you will need to explicitly free somewhere else. If > you don't call FreeTable() again before you're finished processing then > the results of the last query will sit around in memory until your process > terminates. With the alternate implimentation in place you are guaranteed > that the memory will be properly cleaned up after each processing run > instead of having to wait for the next run to clean up the results of the > last one. > > Benjamin. > > Colin Shum <tachyon-oaKApboPmdM9D0CQEJlC7Oqrae++aQT8@xxxxxxxxxxxxxxxx> > Sent by: tachyon-oaKApboPmdM9D0CQEJlC7Oqrae++aQT8@xxxxxxxxxxxxxxxx > 20/11/02 18:38 > Please respond to sqlite > > > To: sqlite-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx > cc: > Subject: Re: [sqlite] sqlite_free_table bug?? > > When sqlite_free_table frees up the memory block, the pointer passed in > is not set back to NULL. Thus on the second access of > sqlite_free_table, it complains with Segmentation fault. > > Should really set the pointer back to NULL before exiting. > > Colin Shum wrote: > > > I am having problems with sqlite_free_table. I tried and cannot call it > > twice in a row. Is that the same as cant be call with "NULL" pointer? > > > char **result; > > char request_saved[300] = "select * from abc"; > > int nrow = 0; > > int ncolumn = 0; > > int rc = 0; > > > > void FreeTable( void ) { > > sqlite_free_table(result); > > } > > > > int foo (void) { > > FreeTable(result); > > rc = sqlite_get_table(db, request_saved, &result, &nrow, > &ncolumn, > > &zErrMsg); > > > > return foo; > > } > > > To unsubscribe from this group, send an email to: > sqlite-unsubscribe-VgYJa0VH1e9BDgjK7y7TUQ@xxxxxxxxxxxxxxxx > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------------------------ Yahoo! Groups Sponsor ---------------------~--> Get 128 Bit SSL Encryption! http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/EbFolB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: sqlite-unsubscribe-VgYJa0VH1e9BDgjK7y7TUQ@xxxxxxxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Weird memory leak: 00123, Steven Frank |
|---|---|
| Next by Date: | Re: Weird memory leak: 00123, ben . carlyle-LNVqYbe/PQpWk0Htik3J/w |
| Previous by Thread: | Re: sqlite_free_table bug??i: 00123, ben . carlyle-LNVqYbe/PQpWk0Htik3J/w |
| Next by Thread: | Weird memory leak: 00123, Steven Frank |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |