Re: sqlite_free_table bug??

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



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/JjlUgA/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/