GNOME Bugzilla – Bug 565942
memleak in gda_holder_set_value () and gda_holder_take_static_value ()
Last modified: 2008-12-30 13:06:48 UTC
I see a memleak using the functions in subject: gda_holder_set_value () and gda_holder_take_static_value (). I suppose it's a problem in the following code GValue *att_value; g_value_set_boolean ((att_value = gda_value_new (G_TYPE_BOOLEAN)), holder->priv->default_forced); gda_holder_set_attribute_static (holder, GDA_ATTRIBUTE_IS_DEFAULT, att_value); gda_value_free (att_value); but I can be wrong.
Created attachment 125480 [details] plain old test file Please have a look at execute_statement () function, where I put some comments for memleak.
Created attachment 125481 [details] valgrind memcheck debug here it is a valgrind execution valgrind --tool=memcheck --leak-check=full --show-reachable=yes --log-file=valgrind_memchek .libs/benchmark /tmp/ff/ It's interesting to see this part ==6653== 4,284,184 bytes in 5,442 blocks are still reachable in loss record 139 of 139 ==6653== at 0x4023D6E: malloc (vg_replace_malloc.c:207) ==6653== by 0x4023EEF: realloc (vg_replace_malloc.c:429) ==6653== by 0x43A4469: g_realloc (in /usr/lib/libglib-2.0.so.0.1600.6) ==6653== by 0x41ED083: g_object_weak_ref (in /usr/lib/libgobject-2.0.so.0.1600.6) ==6653== by 0x40AF156: manager_real_set (gda-attributes-manager.c:173) ==6653== by 0x40E6005: gda_holder_set_attribute (gda-holder.c:1714) ==6653== by 0x40E90AB: gda_holder_set_property (gda-holder.c:541) ==6653== by 0x41F0AB5: g_object_set_valist (in /usr/lib/libgobject-2.0.so.0.1600.6) ==6653== by 0x41F0F15: g_object_set (in /usr/lib/libgobject-2.0.so.0.1600.6) ==6653== by 0x41392A4: gda_sqlite_provider_statement_execute (gda-sqlite-provider.c:1782) ==6653== by 0x40B60EB: gda_connection_statement_execute_v (gda-connection.c:1494) ==6653== by 0x40BD2C0: gda_connection_statement_execute_non_select (gda-connection.c:1622) More: with Anjuta's population the memory used is always growing up as the files are parsed on.
oh, I've also run some tests with different revisions. I saw that maybe the memleak has been inserted with rev 3227.
I can't get valgrind to report this problem with rev #3272: * this single problem is not reported * the quantity of used memory remains the same even when changing the number of times the test is run (the "i" variable in execute_statement()). Ths only mem leak I can find regards providers DSN and AUTH spec strings which are leaked (this will be corrected ASAP).
(In reply to comment #4) > I can't get valgrind to report this problem with rev #3272: > * this single problem is not reported > * the quantity of used memory remains the same even when changing the number of > times the test is run (the "i" variable in execute_statement()). > > Ths only mem leak I can find regards providers DSN and AUTH spec strings which > are leaked (this will be corrected ASAP). > Actually I don't see the bug with rev 3272 too I was probably testing with an inferior revision while trying to understand why Anjuta leaked, sorry. Anyway I found the bug on my code which leaked memory: it happened when I set the last_inserted GdaSet on a gda_connection_statement_execute_non_select () call. I don't know why but I tought either it was just an integer and that it shouldn't be freed, at least on documentation there's no such remark. I think you can close the bug, thanks.
Ok, closing the bug.