GNOME Bugzilla – Bug 743399
GParted 0.19.0-2 segfaults with error in Glib::wrap_register()
Last modified: 2016-04-10 15:24:24 UTC
Well, I have seen a lot with gparted through the versions, but this is one of the hardest-to-handle things I've experienced since a long time. gparted won't start anymore at all! The Fedora people are currently having the very same problem: https://bugzilla.redhat.com/show_bug.cgi?id=1178302 (the latter of which proves that this is NOT a 0.19.x problem) I've done a debug run in a kinda "sandbox" (using apport-retrace) and this is the (devastating) result: Calling gdb command: gdb --ex 'set debug-file-directory /tmp/apport_sandbox_rJxlpW/usr/lib/debug' --ex 'set solib-absolute-prefix /tmp/apport_sandbox_rJxlpW' --ex 'file "/tmp/apport_sandbox_rJxlpW//usr/sbin/gpartedbin"' --ex 'core-file /tmp/apport_core_86Zdd3' GNU gdb (Ubuntu 7.8.2-0ubuntu1) 7.8.2 Copyright (C) 2014 Free Software Foundation, Inc. (...) This GDB was configured as "i686-linux-gnu". (...) Reading symbols from /tmp/apport_sandbox_rJxlpW//usr/sbin/gpartedbin...(no debugging symbols found)...done. [New LWP 3439] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". Core was generated by `gpartedbin'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 234576
For completeness' sake, I will also include the user-level (non-)"results": root@andy-lubuntubox:/home/andy# gparted Failed to get D-Bus connection: Operation not permitted Too few arguments. Segmentation fault (core dumped) Too few arguments. root@andy-lubuntubox:/home/andy#
Thank you Andreas for your interest in GParted. It looks like you also reported this issue to Debian. Debian - gparted crashing during scan https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765283 It is more manageable if the problem is triaged in a single bug report. Since Phillip has already responded in the Debian bug report we should probably do all triaging in that thread. If the problem is with GParted code, then a patch can be placed in this report. Curtis
>It looks like you also reported this issue to Debian. Bingo :) Well I first started reporting it there, then as a second step, I got aware that there are some GParted bugs here as well, so I thought, it's not really looking as if it's _not_ a Debian-specific thing (let alone that I'm no longer using genuine Debian) and "reported it upstream" as you guys would like to put it.
P.S. Second reason is that here I can just add replies; on that last-century Debian bugtracker I always have to write e-mails. To me this _is_ a thing to consider. :P
Hi, With this test program I get a very similar back trace with a crash in Glib::wrap_register. Crashes on Fedora Rawhide (22). OK on Fedora 21. Thanks, Mike /* gcc -g -o test test.cc `pkg-config gtkmm-2.4 --cflags --libs` */ #include <stdlib.h> #include <gtkmm/main.h> int main(int argc, char *argv[]) { Glib::thread_init(); return EXIT_SUCCESS; } $ gdb test GNU gdb (GDB) Fedora 7.8.50.20150108-1.fc22 Reading symbols from test...done. (gdb) run Starting program: /home/fedora/programming/c/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6476c8a in Glib::wrap_register(unsigned long, Glib::ObjectBase* (*)(_GObject*)) () from /lib64/libglibmm-2.4.so.1 (gdb) backtrace
+ Trace 234579
Not surprising. Hence my mentioning of issue #1178302 in RH bugzilla in my OP. You might want to compare there, since unlike me, you do have Fedora at your disposal.
Mike, I think the problem must be somewhere inside libgtkmm.
Let's murrayc join the party.
o/ I saw the debian bug on this today and was a bit confused about it for a while and had a few questions and now I'm thinking the bug is actually not in gparted but in a library *somewhere*, but I'm not sure where. The DBUS messages are particularly interesting but AFAICS, gparted does not make any use of DBUS, so it must be something that one of the libraries is initializing automatically just in case gparted were to use it. Hrm... it is good that you found a simple reproducer Mike. Now to try and understand it... I could imagine that trying to exit the process from the main thread at the same time that the new thread is trying to initialize could cause a problem... but.... gparted doesn't do anything like that does it?
Hi, Note that I have raised bug 743466 - core dump in wrap_register() when calling deprecated Glib::thread_init() https://bugzilla.gnome.org/show_bug.cgi?id=743466 It contains an analysis of the crash as well as a 1 line patch to fix glibmm 2.43.x. Thanks, Mike
Great work, Mike! But now please tell me...why did GParted 0.18.x still work fine? IOW, where are the current changes responsible for these recent crashes?
Ah ok, just saw your presumptions in 743466 (Kjell's changes). Makes lots of sense to me, because these problems indeed started in end of last year's November or beginning of December.
So the problem was in calling Glib::thread_init() without first calling Glib::init()?
Mike, Great detective work on this problem and a solution! Looking at comment #12, if we can work around the problem by inserting a Glib::init() call in front of Glib::thread_init() in src/main.cc then I think it would be worthwhile to make such a change. Andreas and Mike, Would you be able to test such a change? If it works, I would like to include such a fix in tomorrow's release of GParted 0.21.0. Curtis
Hi Curtis, I think that we need to do the relevant research and testing before just adding Glib::init(). Before Glib::thread_init() was deprecated in glibmm 2.31.0, as best I can tell, just using Glib::thread_init() was the documented way to initialise a threaded program instead of using Glib::init(). One of the example threaded programs from glibmm-2.30.0 which just uses Glib::thread_init(). https://git.gnome.org/browse/glibmm/tree/examples/thread/thread.cc?id=2.30.0#n94 I don't want us to rush a change which causes GParted to break on older distributions which use glibmm 2.30.0 and earlier. This crash only only appears when GParted is linked using development release of glibmm 2.43.1 and later. A patch is already upstream in the glibmm repo so I expect the future glibmm 2.44.0 production release will include it. How many distributions use developer releases of packages? Should we just make note of it in the release notes saying that GParted will crash if compiled with developer release of glibmm 2.43.x. Thanks, Mike
Hi Mike, Thanks for the prompt response and looking deeper into Glib::init() and Glib::threa_Init(). > How many distributions use developer releases of packages? As far as I know, there are none. So, we should probably hold off of making such a change as proposed in comment #13. Thanks for the sage advice. :-) I don't think we should include the problem in the release notes because in theory all versions of GParted with Glib::thread_init() would crash with the broken new glibmm-2.43.x development package. Having said that, we should probably keep this bug report open until glibmm-2.44 is released so that anyone encountering the problem can find this report via an Internet search. Thanks to all who helped with a speedy discovery and solution to this problem. Curtis
Umm... if both Debian and Fedora aren't shipping this developer release of glibmm, then how was the problem discovered and reproduced there?
I produced this crash on Fedora Rawhide which is the rolling development distribution with development packages. Looking at the Debian bug, Andreas produced the crash on the as yet unreleased *Ubuntu 15.04 which I assume at this time has development packages. As to Michael's original crash in the Debian bug, I don't know as there is no back trace to know where it crashed.
>Looking at the Debian bug, Andreas produced the crash on the as yet >unreleased *Ubuntu 15.04 which I assume at this time has development >packages. Full house. Vivid (alpha 2) currently ships libglibmm 2.43.2. As an alternative, I could just have downgraded glibmm and things would have worked (pretty sure); just ... don't play with .*glib.* I always say. You'd just break too much stuff. That's why I'm normally reluctant to do this kind of downgrades.
Closing this bug as a duplicate since it was fixed in glibmm by: bug 743466 - core dump in wrap_register() when calling deprecated Glib::thread_init() https://bugzilla.gnome.org/show_bug.cgi?id=743466 *** This bug has been marked as a duplicate of bug 743466 ***