Re: [gnome-db] V4: fix memory leaks

["Vivien Malerba" <vmalerba gmail com>]

On Wed, Jun 4, 2008 at 10:42 PM, Massimo Cora' <maxcvs email it> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Vivien,
>
> Vivien Malerba wrote:
>>
>> A prepared statement object is created and associated with a
>> GdaStatement when the GdaStatement is being executed (if the same
>> GdaStatement is executed several times, then the same prepared
>> statement object is reused). The prepared statement is destroyed when
>> either the GdaStatement changes or is destroyed, so there should not
>> be any mem leak there, but of course there may be bugs...
>>
>> Do you have a test case from which I can investigate?
>
> sure. You need Anjuta [2.5.0 or trunk is ok, with symbol-db building
> enabled].
> Make a /tmp/foo directory, and put inside some .c files. It's not
> necessary that they have some relation between each other.
> Then go on anjuta/plugins/symbol-db/test, and give a
> valgrind -v --log-file=valgrind_output --show-reachable=yes
> - --leak-resolution=high --leak-check=full --partial-loads-ok=yes
> ./.libs/benchmark /tmp/foo/
>
> it'll start populating a db on /tmp/foo/.anjuta_sym_db.db. You'll see
> messages from 'benchmark' and a tail -f on valgrind_output file will
> reveal messages from valgrind.
>
> When it exits I can see on the log many references to libgda funcs that
> seem to leak some bytes. Being the libgda funcs called many times it
> could be the reason of the huge amount of memory used. I'm not anyway
> sure about this.
>

I'll try that ASAP. BTW, the 2.5.0 tarball of Anjuta does not contain
the tables.sql file, so the plugin will not work...

Cheers,

Vivien