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 696201 - Not at all clear how to free all mainloop-related storage
Not at all clear how to free all mainloop-related storage
Status: RESOLVED DUPLICATE of bug 627423
Product: glib
Classification: Platform
Component: mainloop
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-03-20 14:30 UTC by Alan Robertson
Modified: 2015-06-13 17:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alan Robertson 2013-03-20 14:30:24 UTC
I have tried various ways of making sure that all the memory I allocate is freed up at the end of my main program exiting - so that valgrind shows everything as freed.

However, what works in one release, doesn't seem to work in a different release.

If exactly what to do to make sure all the mainloop structures were freed were clearly documented - and what order to do them in, so I could know I was doing it right.  Then if it didn't work out for some reason, I would have a good place to start in diagnosing the problem and working it out - and maybe writing a glib bug report (if that were necessary).

Right now, I can't complain that glib isn't doing it right, because I can't claim that my software isn't the problem, because there isn't a defined procedure that if I followed it that all my mainloop storage (and particularly my objects) would be freed up.

The kinds of results I've seen include:
 It hangs when I try and shut down
 It crashes when I try and shut down
 It gets an error and aborts when I try and shut down (most recently)
 It shuts down apparently correctly

But I tend to get one of these behaviors on one version of glib, and a different behavior from a different version of glib.

I suspect this isn't documented because no one has thought about this carefully.  But maybe I'm wrong.  Nevertheless, I can't figure this out, and I've been using glib mainloop for a very long time.

So, document it, add test cases, test it, and so on...
Comment 1 Allison Karlitskaya (desrt) 2013-03-21 14:42:17 UTC
Hi.  Thanks for the report.

If you're talking about how not to leak memory, then this should be clearly documented and not changing from release to release.  If you've found a place that there is a shortcoming then more details are appreciated.

If you are talking about freeing _all_ allocated heap objects, this is simply not supported in GLib.  We have some other bugs pondering that, but it's not really a priority for us right now.  Bug 627423 talks more about that.
Comment 2 Alan Robertson 2013-03-21 15:24:50 UTC
Let me put in my vote in favor of cleaning up all objects -- but failing that...

What I want to know is how to tell glib's mainloop to clean up all the Glib-related objects I've created while it was running - or at least all _my_ mainloop objects - like my GSources.  Since a GSource is a user-defined structure it can easily have things that really ought to be cleaned up before exiting (child processes that should be killed, etc).

In other words, after I leave the mainloop and before I exit, what is the proper sequence of calls that I should make in order to clean up my GSources.  [I think it's only gsources that are of concern here].  And I want this method to work on all releases of glib.  What should I do, and what should I _not_ do?  And you should explicitly document your decision to not clean up after yourself before exiting.

I appreciate the difficulty have cleaning everything up before exiting - since I do that in my code.  However, without it it is quite difficult to have tests cases that include valgrind - since every release of glib has new things that it never frees up - and adding new uses of glib adds more such detrius.
Comment 3 Alexandre Franke 2015-06-13 17:40:43 UTC
Thanks for taking the time to report this.
What you're describing seems to be covered by bug 627423. Closing as duplicate.

*** This bug has been marked as a duplicate of bug 627423 ***