After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711301 - Memory leak
Memory leak
Status: RESOLVED OBSOLETE
Product: libgda
Classification: Other
Component: MySQL provider
5.1.x
Other Linux
: Normal normal
: ---
Assigned To: malerba
gnome-db Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-02 18:24 UTC by Adrien SCH.
Modified: 2018-09-21 13:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Method used to insert data in the database. (3.69 KB, text/x-csrc)
2013-11-02 18:24 UTC, Adrien SCH.
  Details
Patch to correct 4 related memory leaks (2.31 KB, patch)
2014-04-08 14:17 UTC, Adrien SCH.
none Details | Review

Description Adrien SCH. 2013-11-02 18:24:17 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.
Comment 1 Adrien SCH. 2014-04-08 14:17:14 UTC
Created attachment 273804 [details] [review]
Patch to correct 4 related memory leaks
Comment 2 Adrien SCH. 2014-04-08 14:18:32 UTC
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)
Comment 3 GNOME Infrastructure Team 2018-09-21 13:48:47 UTC
-- 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.