-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 here it is the log file, it's 2.8 MB but compressed only 71Kb. Vivien Malerba wrote: > On Mon, Jun 2, 2008 at 11:19 PM, Massimo Cora' <maxcvs email it> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, >> >> I'm noticing some big memleaks while using mass prepared statments >> queries. They're at most always the same [around 50 different queries]. >> While I'm not 100% sure that it isn't my application [Anjuta with >> symbol-db] the one that leaks, on the other side Valgrind says nothing >> when I debug it. So the suspect that it could be libgda comes to my mind. >> Is there an easy way to debug libgda in its deeper levels? >> Giving out some numbers: I see a 200MB memory allocation after a >> population from ~800 files, getting >> sqlite> select count (*) from symbol; >> 26183 >> sqlite> select count (*) from sym_kind; >> 13 >> sqlite> select count (*) from sym_type; >> 22515 >> sqlite> select count (*) from scope; >> 19788 >> >> is prepared statements saved on a static memory? > > 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? > > Cheers, > > Vivien > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIRv6WcfVTgMRILk0RAkT8AKCA6363TfxYdgIxi3FcxU2/q4P6YQCfa1r3 9Pzp4CeeB8cOViAz2YIrEJg= =BKnO -----END PGP SIGNATURE-----
Attachment:
valgrind_output.11991.tar.bz2
Description: application/bzip