-----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. thanks and regards, Massimo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIRv5DcfVTgMRILk0RArAbAJwLQxihq51ARV1xHv/4RKEUZXuQBgCfcwo7 MARL2OE856DDD2Xii0cT0Aw= =mfbZ -----END PGP SIGNATURE----- _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
