GNOME Bugzilla – Bug 729800
Prevent GSource double-destroy warning messages
Last modified: 2014-06-11 06:22:03 UTC
When run from within a shell, GParted gives me many error messages of the following form: (gpartedbin:25545): GLib-CRITICAL **: Source ID 7 was not found when attempting to remove it I've sourced all of these warnings to the PipeCapture::~PipeCapture() method (see the attached backtrace). When run with a debug version of glib and breaking on g_source_destroy_internal, it appears that the GSource is released before this destructor, as the result of the GSource's dispatch callback returning false.
Created attachment 276140 [details] Backtrace of the error message A backtrace of the write call that printed the error message.
Created attachment 276141 [details] [review] Patch to fix the error messages This patch checks for the existence of the GSource before destroying it, since the GSource can be destroyed in the main loop at any time if its callback returns false.
Hi Geoff, Thank you for investigating this issue and producing a patch. I've not seen this error before, even though I'm always running GParted from the command line. So that I might reproduce the error can you tell me the following: * version of GParted * version of distribution * steps used to trigger the error * anything else you thing might be relevant Thanks, Mike
Hi Phillip, Would you be able to have a look at the patch in this bug and comment. This is more your area of expertise than mine. Thanks, Mike
Created attachment 276296 [details] Full GDB session to show earlier destroys
Created attachment 276297 [details] Full output from running git HEAD
Created attachment 276299 [details] [review] 0001-Prevent-GSource-double-destroy-warning-messages-7298.patch
I had prepared a patch to fix this a week or two ago and thought I sent it in, but it must have been lost in the shuffle ( it's been a hectic two weeks at work ). I've recreated it and here it is.
That should do the trick.
Hi Geoff, Mike, and Phillip, The warning message appears when running GParted in recent Debian SID releases, and also the ubuntu 14.04 LTS release. There are two ubuntu launchpad bug reports regarding this problem: 1) (gpartedbin:6851): GLib-CRITICAL **: Source ID 54 was not found when attempting to remove it https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1307201 2) GLib-CRITICAL **: Source ID was not found when attempting to remove it - warning when leaving Network menu of g-c-c https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1264368 Quote from an upstream (bugzilla.gnome.org) comment: https://bugzilla.gnome.org/show_bug.cgi?id=721369 GLib recently started throwing a warning when g_source_remove() is passed garbage (as per warning). Your applications have probably been broken for a while, and there's no telling what could actually have happened in the past when g_source_remove() would happily close any random source because the programmer got the wrong argument to g_source_remove(). Thank you Geoff for reporting this problem and providing a patch. :-) I have tested the patches in comment #2, and comment #7. Both patches address the problem of the warning message being displayed. The first one handles the problem when the class is closed, and the second patch ensures that there is always a sourceid to be freed. While both patches work, I lean towards the patch in comment #7 because it addresses the cause of a sourceid not being found. Normally we do not have the luxury of two patches. However since we do, and both do address the problem, we need to decide on which patch to use. If there are no objections in the next few days, I will commit patch #7. Curtis
Doh! The last sentence should read: If there are no objections in the next few days, I will commit the patch in comment #7.
Thanks Curtis, I've just got to the same conclusion that the message is coming from glib 2.40 as found in Ubuntu 14.04. This is the extra checking added to Glib which generates the critical error: https://git.gnome.org/browse/glib/commit/?id=a919be3d39150328874ff647fb2c2be7af3df996 gmain: Warn when g_source_remove() fails I agree go with Phillip's patch from comment #7. Also tested successfully on the following distros: Fedora 20 w/ glib 2.38 CentOS 5.10 w/ glib 2.12.3 Thanks, Mike
I also noticed that when you click on the expander widgets in the operation details view, you still get some of these messages, but this appears to be due to a bug in gtk rather than gparted ( on Ubuntu 14.04 ).
The patch in comment #7 has been committed to the git master branch for inclusion in the next release of GParted. The relevant git commit can be viewed at the following link: Prevent GSource double-destroy warning messages (#729800) https://git.gnome.org/browse/gparted/commit/?id=2e7b5d05a6324c1370248af93925cbc95b9db0ac
Well, I wanted to give this a test (Lubuntu 14.04), but I can't: https://launchpad.net/~andykimpe/+archive/gparted I dunno why the behavior is so strange, considering that 0.18.0-1 (the "stock" version) works without a hitch. $ sudo gparted Password: "Cannot open display" ??? Why does that happen? 0.18.0-1 doesn't bail out that way. Needless to say that even xhost +localhost and other silly tricks did not work.
Thank you Andreas for trying to help improve GParted with your testing. The "cannot open display" message is often related to a problem with the X-server setup, firewall configuration, or environment settings. For example you could try running any graphical application and receive the same error message (e.g., sudo gedit). I suggest searching on the Internet to get ideas on things to try to resolve the problem. You might also try downloading the source code and compiling yourself. See: http://gparted.org/git.php
This enhancement was included in the GParted 0.19.0 release on June 10, 2014.
>The "cannot open display" message is often related to a problem with the >X-server setup, firewall configuration, or environment settings. >I suggest searching on the Internet to get ideas on things to try to resolve >the problem. Nope! I refuse to go "back to Linux school". I think it's the packager who made that mistake, since 0.18.0-1 DOES work without problems, and 0.18.0-3 no longer does. This is why I don't see any reason to tweak anything else if the 0.18.0-1 version doesn't show that odd behavior. Needless to say, that 0.18.0-3 is a PPA package, thus prone to quirks. p.s. thanks for releasing 0.19