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 545977 - GdaDataModel memory leak
GdaDataModel memory leak
Status: RESOLVED FIXED
Product: libgda
Classification: Other
Component: Client library
unspecified
Other All
: Normal critical
: ---
Assigned To: malerba
gnome-db Maintainers
Depends on:
Blocks: 358479
 
 
Reported: 2008-08-02 13:14 UTC by Massimo Cora'
Modified: 2008-08-30 12:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example of memory leak (4.39 KB, text/x-csrc)
2008-08-02 13:17 UTC, Massimo Cora'
Details

Description Massimo Cora' 2008-08-02 13:14:03 UTC
Please describe the problem:
Reporting here the mail from mailing list sent on 08/01/2008

I see a strange behaviour with gda_connection_statement_execute_select
() and the unreffing of the returned GdaDataModel.
I slightly modified the samples/SimpleExample/example.c test file to let
you see the memory leak. Just launch gnome-system-monitor and see how
the process takes more and more memory.

In my Anjuta's population process this leak grows till 200+ Mb.

I hope I'm doing the right calls, but seeing your examples it seems it's
all ok.



Steps to reproduce:
1. see the attached example file.
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
yes

Other information:
Comment 1 Massimo Cora' 2008-08-02 13:17:46 UTC
Created attachment 115728 [details]
Example of memory leak

With libgda revision 3186 this example bring to a memory leak.
See execute_statement (). I'm setting a random parameter and executing a select on a simple db. The GdaDataModel returned is unreffed but it seems like that not all the memory is freed.
Comment 2 Massimo Cora' 2008-08-20 20:24:34 UTC
Bug still present with revision 3191.
Comment 3 malerba 2008-08-25 15:37:14 UTC
It works for me (the mem used is 5M), but you need to add a call to gda_connection_clear_events_list (cnc)
after any call to
gda_connection_statement_execute_select()

Maybe this should be changed as most likely people will forget to call this function...

Tell me if it works when adding gda_connection_clear_events_list().
Comment 4 Massimo Cora' 2008-08-25 17:04:04 UTC
(In reply to comment #3)
> It works for me (the mem used is 5M), but you need to add a call to
> gda_connection_clear_events_list (cnc)
> after any call to
> gda_connection_statement_execute_select()
> 
> Maybe this should be changed as most likely people will forget to call this
> function...
> 
> Tell me if it works when adding gda_connection_clear_events_list().
> 

yes it works with this call and the example.
I also think it's better to make this call an automatic one because it's easy to forget it.
Memory on Anjuta still grows up, but I put this call only after a complete file scanning, not after any gda_connection_statement_execute_select (), they're too many :)

thanks and regards,
Massimo

Comment 5 malerba 2008-08-29 12:25:06 UTC
In the latest SVN trunk revision (rev #3194), the events list is automatically cleared before each new statement execution. Can you check it's OK so I can close this bug?
Comment 6 Massimo Cora' 2008-08-29 16:40:43 UTC
All fine for me, the bug can be closed,
thanks and regards,
Massimo

Comment 7 malerba 2008-08-30 12:49:47 UTC
Ok, closing it then!