On Wed, Jun 4, 2008 at 10:42 PM, Massimo Cora' <[EMAIL PROTECTED]> 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 _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
