GNOME Bugzilla – Bug 711301
Memory leak
Last modified: 2018-09-21 13:48:47 UTC
Created attachment 258814 [details] Method used to insert data in the database. Hello guys, I was debugging my soft with valgrind and I observed few memory leak (or not) in libgda. This is the valgrind dump (libgda part). ==20824== 112 bytes in 1 blocks are definitely lost in loss record 3,322 of 4,410 ==20824== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==20824== by 0x60BAAA0: g_malloc0 (gmem.c:189) ==20824== by 0x5B17C3D: gda_sql_statement_select_new (gda-statement-struct-select.c:60) ==20824== by 0x5B117AD: gda_sql_statement_new (gda-statement-struct.c:112) ==20824== by 0xB1E5279: gda_mysql_provider_statement_execute (gda-mysql-provider.c:2019) ==20824== by 0x5A9DD05: gda_connection_statement_execute_v (gda-connection.c:3544) ==20824== by 0x5A9F6CA: gda_connection_statement_execute (gda-connection.c:3725) ==20824== by 0x6788F9B: ast_db_event_new_entry_full (ast_db.c:872) ==20824== by 0x67891E3: ast_db_event_information_new_entry (ast_db.c:918) ==20824== by 0x97AC402: ??? ==20824== by 0x97AC212: ??? ==20824== by 0x4E3B1CA: ast_base_source_start (ast_base_source.c:290) ==20824== ==20824== 192 bytes in 1 blocks are definitely lost in loss record 3,628 of 4,410 ==20824== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==20824== by 0xC0B88FE: my_thread_init (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0) ==20824== by 0xC09286C: mysql_server_init (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0) ==20824== by 0xC098B5E: mysql_init (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0) ==20824== by 0xB1E0E28: real_open_connection (gda-mysql-provider.c:531) ==20824== by 0xB1E377E: gda_mysql_provider_open_connection (gda-mysql-provider.c:677) ==20824== by 0x5A9844D: gda_connection_open (gda-connection.c:1642) ==20824== by 0x5A98A70: gda_connection_open_from_string (gda-connection.c:1415) ==20824== by 0x6789DF4: ast_db_get_connection (ast_db.c:1205) ==20824== by 0x97AD712: ??? ==20824== by 0x97AE445: ??? ==20824== by 0x60D69B4: g_thread_proxy (gthread.c:801) ==20824== 963 (144 direct, 819 indirect) bytes in 3 blocks are definitely lost in loss record 4,090 of 4,410 ==20824== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==20824== by 0x60BAAA0: g_malloc0 (gmem.c:189) ==20824== by 0x5B11681: gda_sql_statement_copy (gda-statement-struct.c:139) ==20824== by 0x5AED627: gda_statement_get_property (gda-statement.c:311) ==20824== by 0x5E3593D: g_object_get_valist (gobject.c:1289) ==20824== by 0x5E35D96: g_object_get (gobject.c:2104) ==20824== by 0x5AFC549: gda_rewrite_statement_for_null_parameters (gda-util.c:1653) ==20824== by 0xB1E419A: gda_mysql_provider_statement_execute (gda-mysql-provider.c:2400) ==20824== by 0x5A9DD05: gda_connection_statement_execute_v (gda-connection.c:3544) ==20824== by 0x5A9F6CA: gda_connection_statement_execute (gda-connection.c:3725) ==20824== by 0x6788F9B: ast_db_event_new_entry_full (ast_db.c:872) ==20824== by 0x67891E3: ast_db_event_information_new_entry (ast_db.c:918) I had a quick look in gda-util.c (last leak) and I modified my clone like this to resolve the leak : gboolean gda_rewrite_statement_for_null_parameters (GdaStatement *stmt, GdaSet *params, GdaStatement **out_stmt, GError **error) { GdaSqlStatement *sqlst; gboolean mod; g_return_val_if_fail (GDA_IS_STATEMENT (stmt), FALSE); g_return_val_if_fail (!params || GDA_IS_SET (params), FALSE); if (out_stmt) *out_stmt = NULL; if (!params) return FALSE; g_object_get ((GObject*) stmt, "structure", &sqlst, NULL); if (gda_rewrite_sql_statement_for_null_parameters (sqlst, params, &mod, error)) { if (out_stmt) { if (mod) { *out_stmt = g_object_new (GDA_TYPE_STATEMENT, "structure", sqlst, NULL); //gda_sql_statement_free (sqlst); } } gda_sql_statement_free(sqlst); return mod; }, and the else { /* error => leave *out_stmt to %NULL */ return TRUE; } } I really don't know if this solution may be a good one. For the two first leak, first, my guess is that my connection object still have a reference (inside gda, maybe a statement, I validated twice that my connection is unref after my insert), but I have any glue how to resolve this part. Attach : my insert method.
Created attachment 273804 [details] [review] Patch to correct 4 related memory leaks
The previous patch also fix the following memory leaks : ==00:00:00:07.808 3268== 820 (320 direct, 500 indirect) bytes in 10 blocks are definitely lost in loss record 2,219 of 2,365 ==00:00:00:07.808 3268== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==00:00:00:07.808 3268== by 0x4E7FA38: g_malloc (gmem.c:159) ==00:00:00:07.808 3268== by 0x4E92C72: g_slice_alloc (gslice.c:1003) ==00:00:00:07.808 3268== by 0x4E931B5: g_slice_alloc0 (gslice.c:1029) ==00:00:00:07.808 3268== by 0x5AF0889: g_type_create_instance (gtype.c:1872) ==00:00:00:07.808 3268== by 0x5AD50B8: g_object_constructor (gobject.c:1849) ==00:00:00:07.808 3268== by 0x5AD66E3: g_object_newv (gobject.c:1713) ==00:00:00:07.808 3268== by 0x5AD6EC5: g_object_new_valist (gobject.c:1830) ==00:00:00:07.808 3268== by 0x5AD71D3: g_object_new (gobject.c:1545) ==00:00:00:07.808 3268== by 0x51690CD: gda_connection_point_available_event (gda-connection.c:2606) ==00:00:00:07.808 3268== by 0xAD17585: gda_mysql_provider_statement_execute (gda-mysql-provider.c:2812) ==00:00:00:07.808 3268== by 0x51705F8: gda_connection_statement_execute_v (gda-connection.c:3544) ==00:00:00:07.808 3268== by 0x517200B: gda_connection_statement_execute (gda-connection.c:3725) ==00:00:00:07.808 3268== by 0x54F8378: ast_db_record_new_full (ast_db.c:652) ==00:00:00:07.808 3268== by 0x400909: main (main.c:24) --------------------------------------------------------------------- ==00:00:00:07.941 18943== by 0x4E7FA38: g_malloc (gmem.c:159) ==00:00:00:07.941 18943== by 0x4E92C72: g_slice_alloc (gslice.c:1003) ==00:00:00:07.941 18943== by 0x4E93F92: g_slist_append (gslist.c:222) ==00:00:00:07.941 18943== by 0x51BF065: default_render_param_spec (gda-statement.c:1395) ==00:00:00:07.941 18943== by 0xAD13E8E: mysql_render_expr (gda-mysql-provider.c:1647) ==00:00:00:07.941 18943== by 0xAD163CE: mysql_render_insert (gda-mysql-provider.c:1565) ==00:00:00:07.941 18943== by 0xAD155DF: gda_mysql_provider_statement_to_sql (gda-mysql-provider.c:1484) ==00:00:00:07.941 18943== by 0xAD1569F: real_prepare (gda-mysql-provider.c:1826) ==00:00:00:07.941 18943== by 0xAD159DC: gda_mysql_provider_statement_prepare (gda-mysql-provider.c:1917) ==00:00:00:07.941 18943== by 0xAD17386: gda_mysql_provider_statement_execute (gda-mysql-provider.c:2208) ==00:00:00:07.941 18943== by 0x51705F8: gda_connection_statement_execute_v (gda-connection.c:3544) ==00:00:00:07.941 18943== by 0x517200B: gda_connection_statement_execute (gda-connection.c:3725) ==00:00:00:07.941 18943== by 0x54F8378: ast_db_record_new_full (ast_db.c:652) ==00:00:00:07.941 18943== by 0x40095C: main (main.c:24)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgda/issues/75.