The "drakconf" program crashed. Drakbug-18.32 caught it. Had been in MCC -> hardware. Closed the hardware window, and almost immediately (i.e. within 1 sec on a slow older PC) closed the MCC window. Reproducible; This has happened several times under these exact circumstances. SEGV Glibc's trace: 0: /usr/lib/libDrakX/auto/c/stuff/stuff.so(+0x9550) [0x7f1abcc3f550] 1: /lib64/libperl.so.5.32(Perl_pp_entersub+0x217) [0x7f1abc9aad97] 2: /lib64/libperl.so.5.32(Perl_runops_standard+0x2e) [0x7f1abc9a140e] 3: /lib64/libperl.so.5.32(Perl_call_sv+0x364) [0x7f1abc9083e4] 4: /lib64/libperl.so.5.32(Perl_perly_sighandler+0x229) [0x7f1abc98fca9] 5: /lib64/libjavascriptcoregtk-4.0.so.18(+0x133e1aa) [0x7f1ab630d1aa] 6: /lib64/libc.so.6(+0x3a3f0) [0x7f1abc7153f0] 7: /lib/../lib64/libgobject-2.0.so.0(+0x25c4c) [0x7f1abb97fc4c] 8: /lib/../lib64/libgobject-2.0.so.0(g_signal_emit_valist+0xc79) [0x7f1abb985949] 9: /lib/../lib64/libgobject-2.0.so.0(g_signal_emit+0x82) [0x7f1abb985d82] 10: /lib/../lib64/libgobject-2.0.so.0(+0x181d4) [0x7f1abb9721d4] 11: /lib/../lib64/libgobject-2.0.so.0(+0x17a36) [0x7f1abb971a36] 12: /lib/../lib64/libgobject-2.0.so.0(+0x1915c) [0x7f1abb97315c] 13: /lib/../lib64/libgobject-2.0.so.0(g_object_new_valist+0x414) [0x7f1abb974af4] 14: /lib/../lib64/libgobject-2.0.so.0(g_object_new+0x8c) [0x7f1abb974e4c] 15: /lib64/libgtk-3.so.0(+0x37b281) [0x7f1aba6a3281] 16: /lib64/libgtk-3.so.0(+0x8e54a) [0x7f1aba3b654a] 17: /lib64/libgdk-3.so.0(+0x2dd59) [0x7f1aba256d59] 18: /lib/../lib64/libglib-2.0.so.0(+0x4c327) [0x7f1abb87f327] 19: /lib/../lib64/libglib-2.0.so.0(g_main_context_dispatch+0x147) [0x7f1abb883387] Perl's trace: drakbug::bug_handler() called from /usr/lib/libDrakX/drakbug.pm:41 drakbug::__ANON__() called from /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm:67 (eval)() called from /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm:67 Glib::Object::Introspection::__ANON__() called from /usr/lib/libDrakX/mygtk3.pm:1562 mygtk3::flush() called from /usr/lib/libDrakX/ugtk3.pm:68 ugtk3::gtkflush() called from /usr/lib/libDrakX/ugtk3.pm:875 ugtk3::flush() called from /usr/lib/libDrakX/ugtk3.pm:881 ugtk3::exit() called from /usr/lib/libDrakX/ugtk3.pm:891 ugtk3::END() called from /usr/libexec/drakconf:0 (eval)() called from /usr/libexec/drakconf:0 Theme name: Adwaita-Xfce Kernel version = 5.7.8-desktop-1.mga8 Distribution=Mageia release 8 (Cauldron) for x86_64 CPU=Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
Thanks for the report, Tony. > MCC -> hardware. Closed the hardware window, > and almost immediately closed the MCC window puzzles me, because closing the Hardware window is synonymous with closing MCC. (I have just tried it). Do you mean one of the hardware 'applications' (like the first one 'Scan & configure hardware'), which do indeed return to MCC when closed. The windows close 'X' is identically positioned, so a sort of double click is possible to close first the 'application' and then MCC. Trying this on a modest system, I could not reproduce the fault. Can you say whether you know that it does not happen if you pause even briefly between closing the subordinate then parent MCC windows? I do not think this is the same as bug 22968, where the drakconf crash is ill defined. Assigning to tools maintainers.
CC: (none) => lewyssmithAssignee: bugsquad => mageiatools
*** Bug 27014 has been marked as a duplicate of this bug. ***
CC: (none) => jeevanism
*** Bug 27015 has been marked as a duplicate of this bug. ***
CC: (none) => tarazed25
CC: (none) => olav
Despite the way I initially presented this, I think it just segfaults on MCC exit. Tony
(In reply to Tony Blackwell from comment #4) > Despite the way I initially presented this, I think it just segfaults on MCC > exit. > Tony I agree. I always get a seg fault upon exit, no navigation required. I.e su - root mcc & close mcc Happens on mga7 and cauldron. I also wonder why it wants to call home. (mcc:29039): dbind-WARNING **: 23:19:36.519: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-DifzUOEjgq: Connection refused Ignore the following Glib::Object::Introspection & Gtk3 warnings (drakconf:29040): dbind-WARNING **: 23:19:36.811: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-DifzUOEjgq: Connection refused Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525. GLib-LOG **: posix_spawn avoided (child_setup specified) at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 67. GLib-LOG **: posix_spawn avoided (child_setup specified) at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 67. (WebKitWebProcess:29054): dbind-WARNING **: 23:19:37.419: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-DifzUOEjgq: Connection refuse
CC: (none) => bittwister2
I do not get a segfault here on my Mageia 7 x86_64 system ... [root@x3 ~]# mcc Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525. GLib-LOG **: posix_spawn avoided (child_setup specified) at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 67. GLib-LOG **: posix_spawn avoided (child_setup specified) at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 67. [root@x3 ~]# No idea why it's happening on that system. As to "call home", that is not what is happening. It's trying to connect to dbus which is used to communicate between programs running on the same system. It does seem strange that it's trying to use /tmp/dbus-DifzUOEjgq. With mcc running, "lsof -n |grep socket" shows my system is using /run/dbus/system_bus_socket
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #6) > I do not get a segfault here on my Mageia 7 x86_64 system ... Not too surprising to me. Out-of-the-box setup does not enable trapping segment faults and create core files. I find it helps to find occasional hidden problem. I have ~/.bashrc run a check for score files so that the next xterm points out I had one. Example: -rw------- 1 bittwister bittwister 2968514560 Jul 31 00:12 /var/tmp/Decoder_443_11.core -rw------- 1 root root 172789760 Jul 30 22:22 /var/tmp/drakconf_17188_11.core # from wb ck_4_core # There is a /var/tmp/*core file. To remove it, run rm --force /var/tmp/*core* Hmmm, gotta figure out what I did to cause the decoder fault. > > It does seem strange that it's trying to use /tmp/dbus-DifzUOEjgq. With mcc > running, "lsof -n |grep socket" shows my system is using > /run/dbus/system_bus_socket You know much more than me about dbus. I could expect a problem on this node since I am in the sudo list, but not on the test bed node since I used ssh to run the test.
Using a system where I've connected used ssh and then "su -", running mcc and then exiting I get the dbus connection messages. Running mcc under strace shows # grep dbus strace.txt|grep connect 14219 connect(4, {sa_family=AF_UNIX, sun_path=@"/tmp/dbus-Vn7V8TJ4VY"}, 23) = -1 ECONNREFUSED (Connection refused) 14221 connect(5, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 110) = 0 14221 connect(7, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 30) = 0 14221 connect(7, {sa_family=AF_UNIX, sun_path=@"/tmp/dbus-Vn7V8TJ4VY"}, 23) = -1 ECONNREFUSED (Connection refused) 14236 connect(13, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 110 <unfinished ...> 14235 connect(6, {sa_family=AF_UNIX, sun_path=@"/tmp/dbus-Vn7V8TJ4VY"}, 23) = -1 ECONNREFUSED (Connection refused) 14260 connect(18, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 110 <unfinished ...> Both systems are running Mageia 7 x86_64. While it does try the /tmp location for the socket first, it then falls back to the /run location successfully. I don't know why it tries the /tmp location first. It uses both the /tmp and /run locations successfully when run on a normal (not ssh) root session. Still no segfault, which does show up with default settings. The core dumps do not, but the segfault message would still show in the terminal and in the strace output.
*** Bug 27078 has been marked as a duplicate of this bug. ***
CC: (none) => pleny29
*** Bug 27451 has been marked as a duplicate of this bug. ***
CC: (none) => jm.sarat
*** Bug 27448 has been marked as a duplicate of this bug. ***
*** Bug 27708 has been marked as a duplicate of this bug. ***
CC: (none) => amaranthine.technology
This is happening too often, even though it seems to nearly always be one-off. Raising its importance accordingly.
Summary: drakconf segfaulted => drakconf segfaulted on exiting MCCPriority: Normal => High
Note that bug 22708 is the first to report this for Mageia 7, all the others are for cauldron. I note that near the top of the backtrace is libjavascriptcoregtk-4.0.so.18. An update to the package containing that library was recently released (build date 2020-11-24), going from version 2.28.4 to 2.30.3. So if we now start getting more reports for Mageia 7, that is probably a good clue to what is triggering this bug.
CC: (none) => mageia
*** Bug 27743 has been marked as a duplicate of this bug. ***
CC: (none) => pi.astra
*** Bug 27754 has been marked as a duplicate of this bug. ***
CC: (none) => gillou260
*** Bug 27763 has been marked as a duplicate of this bug. ***
CC: (none) => daniel.monsegu
*** Bug 27768 has been marked as a duplicate of this bug. ***
*** Bug 27770 has been marked as a duplicate of this bug. ***
CC: (none) => domisse
5 bugs above against Mageia 7. Note: several come from a xfce install but I did see one in a M7 Plasma installation. Also, several involve /usr/lib64/libjavascriptcoregtk-4.0.so.18.
CC: (none) => ouaurelien
Status comment: (none) => drakconf-13.23-1.mga7Whiteboard: (none) => MGA7TOO
*** Bug 27718 has been marked as a duplicate of this bug. ***
CC: (none) => codebuddy
I have upped the severity because, although user functionality does not seem to suffer, they are seeing (& reporting) the fault, and think something has gone wrong. OTOH Mageia are getting too many of these. Downgrade Severity to Normal if you see fit.
Severity: minor => majorCC: lewyssmith => (none)
I fail to reproduce that (at least on Cauldron)
CC: (none) => thierry.vignaud
*** Bug 27799 has been marked as a duplicate of this bug. ***
CC: (none) => ruben33en-mandriva
*** Bug 27801 has been marked as a duplicate of this bug. ***
CC: (none) => vbcoen
*** Bug 27813 has been marked as a duplicate of this bug. ***
CC: (none) => paul.blackburn
*** Bug 27812 has been marked as a duplicate of this bug. ***
*** Bug 27924 has been marked as a duplicate of this bug. ***
CC: (none) => zeheron
*** Bug 27991 has been marked as a duplicate of this bug. ***
CC: (none) => johnms
I have never been able to reproduce this. Can anyone on CC reproduce it using gdb with debug info installed to get a more helpful back trace?
It does not reproduce every time. I wonder if it's totally random. But I do see it only when I close the window with the X on upper right corner, not by doing File->Quit
*** Bug 28009 has been marked as a duplicate of this bug. ***
CC: (none) => jneri
*** Bug 28016 has been marked as a duplicate of this bug. ***
If I just open drakconf and then exit there is no segfault. If I open drakconf, then in "Software management" I select "Configure media sources for install and update", then "close", then exit (from drakconf). I get a segfault. (See also: 'lspcidrake -v' attachment - filename: 2021_01_05_drakconf_segfault_lspcidrake-v.txt) The "drakconf" program has segfaulted with the following error: SEGV Glibc's trace: 0: /usr/lib/libDrakX/auto/c/stuff/stuff.so(+0x95d5) [0x7f3670f375d5] 1: /lib64/libperl.so.5.32(Perl_pp_entersub+0x217) [0x7f3670ca8f47] 2: /lib64/libperl.so.5.32(Perl_runops_standard+0x2e) [0x7f3670c9f4ee] 3: /lib64/libperl.so.5.32(Perl_call_sv+0x364) [0x7f3670c063d4] 4: /lib64/libperl.so.5.32(Perl_perly_sighandler+0x229) [0x7f3670c8dd19] 5: /lib64/libjavascriptcoregtk-4.0.so.18(+0x134cf7a) [0x7f366a472f7a] 6: /lib64/libc.so.6(+0x3b580) [0x7f3670a13580] 7: /lib/../lib64/libgobject-2.0.so.0(+0x25d5c) [0x7f366fb8bd5c] 8: /lib/../lib64/libgobject-2.0.so.0(g_signal_emit_valist+0xc79) [0x7f366fb91a59] 9: /lib/../lib64/libgobject-2.0.so.0(g_signal_emit+0x82) [0x7f366fb91e92] 10: /lib/../lib64/libgobject-2.0.so.0(+0x18284) [0x7f366fb7e284] 11: /lib/../lib64/libgobject-2.0.so.0(+0x17ad6) [0x7f366fb7dad6] 12: /lib/../lib64/libgobject-2.0.so.0(+0x1922c) [0x7f366fb7f22c] 13: /lib/../lib64/libgobject-2.0.so.0(g_object_new_valist+0x414) [0x7f366fb80bd4] 14: /lib/../lib64/libgobject-2.0.so.0(g_object_new+0x8c) [0x7f366fb80f2c] 15: /lib64/libgtk-3.so.0(+0x37d221) [0x7f366e8db221] 16: /lib64/libgtk-3.so.0(+0x8f64a) [0x7f366e5ed64a] 17: /lib64/libgdk-3.so.0(+0x2ed59) [0x7f366e48ad59] 18: /lib/../lib64/libglib-2.0.so.0(+0x4c757) [0x7f366fa86757] 19: /lib/../lib64/libglib-2.0.so.0(g_main_context_dispatch+0x15e) [0x7f366fa8a8de] Perl's trace: drakbug::bug_handler() called from /usr/lib/libDrakX/drakbug.pm:41 drakbug::__ANON__() called from /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm:67 (eval)() called from /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm:67 Glib::Object::Introspection::__ANON__() called from /usr/lib/libDrakX/mygtk3.pm:1562 mygtk3::flush() called from /usr/lib/libDrakX/ugtk3.pm:68 ugtk3::gtkflush() called from /usr/lib/libDrakX/ugtk3.pm:875 ugtk3::flush() called from /usr/lib/libDrakX/ugtk3.pm:881 ugtk3::exit() called from /usr/lib/libDrakX/ugtk3.pm:891 ugtk3::END() called from /usr/libexec/drakconf:0 (eval)() called from /usr/libexec/drakconf:0 Used theme: Menta To submit a bug report, click on the report button. This will open a web browser window on Bugzilla where you'll find a form to fill in. The information displayed above will be transferred to that server It would be very useful to attach to your report the output of the following command: 'lspcidrake -v'.
Created attachment 12181 [details] 2021_01_05_drakconf_segfault_lspcidrake-v.txt Output from 'lspcidrake -v' after drakconf segfault.
Created attachment 12182 [details] strace-mcc-sigsegv on exiting If I open drakconf, then in "Software management" I select "Configure media sources for install and update", then "close", then exit (from drakconf). I get a segfault. Reproduced. installed packages: lib64glib2.0_0-debuginfo-2.66.4-1.mga8.x86_64 mar. 05 janv. 2021 17:10:34 lib64javascriptcoregtk4.0_18-debuginfo-2.30.4-1.mga8.x86_64 mar. 05 janv. 2021 17:10:33 lib64gtk+3_0-debuginfo-3.24.24-1.mga8.x86_64 mar. 05 janv. 2021 17:10:33 webkit2-debuginfo-2.30.4-1.mga8.x86_64 mar. 05 janv. 2021 17:10:32 perl-debuginfo-5.32.0-10.mga8.x86_64 mar. 05 janv. 2021 17:10:32 perl-base-debuginfo-5.32.0-10.mga8.x86_64 mar. 05 janv. 2021 17:10:32 webkit2-debugsource-2.30.4-1.mga8.x86_64 mar. 05 janv. 2021 17:10:31 perl-debugsource-5.32.0-10.mga8.x86_64 mar. 05 janv. 2021 17:10:30 gtk+3.0-debuginfo-3.24.24-1.mga8.x86_64 mar. 05 janv. 2021 17:09:33 glibc-debuginfo-2.32-9.mga8.x86_64 mar. 05 janv. 2021 17:09:32 glib2.0-debuginfo-2.66.4-1.mga8.x86_64 mar. 05 janv. 2021 17:09:32 glib2.0-debugsource-2.66.4-1.mga8.x86_64 mar. 05 janv. 2021 17:09:31 glibc-debugsource-2.32-9.mga8.x86_64 mar. 05 janv. 2021 17:09:30 gtk+3.0-debugsource-3.24.24-1.mga8.x86_64 mar. 05 janv. 2021 17:09:29 rpmdrake-6.31-1.mga8.noarch mar. 05 janv. 2021 17:08:00 drakxtools-backend-debuginfo-18.39-1.mga8.x86_64 mar. 05 janv. 2021 17:08:00 glibc-devel-2.32-9.mga8.x86_64 mar. 05 janv. 2021 17:07:59 glibc-2.32-9.mga8.x86_64 mar. 05 janv. 2021 17:07:58 drakxtools-debugsource-18.39-1.mga8.x86_64 mar. 05 janv. 2021 17:07:58 strace mcc see attached file
Created attachment 12183 [details] full backtrace from segfault Thanks Paul. The key to reproducing it for me was to use the File menu to quit both drakrpm-edit-media and drakconf - using the window close button (as I usually do) did not cause the segfault.
@Martin, how you obtain it?
(In reply to Aurelien Oudelet from comment #38) > @Martin, how you obtain it? su - gdb perl run /usr/libexec/drakconf < use GUI to trigger the fault > bt
I was looking into it earlier and I got the same stacktrace 100% of the time starting drakconf and using "File > Quit", however I couldn't get more information as it seems it doesn't use the debuginfo in the "Mageia Bug Report Tool". After reading the code I found there is a DISABLE_DRAKBUG env variable, but setting it does not help. After looking more into it I found /usr/libexec/drakconf and running it directly in gdb works and gives the one from comment #37 which looked totally different so I was still investigating. It actually is not, the one caught by the tool just has several more levels to catch/handle the crash, the only strange level is the libjavascriptcoregtk, maybe it wraps the SIGSEGV handler.
The crash happens when CORE::exit(@_); is called in standalone.pm. Replacing it with c::_exit(@_) fixes the crash so I guess something regsitered with atexit is what is causing the crash.
CC: (none) => pterjan
File->Quit on its own is not enough to trigger the bug for me. I guess there's a race with Perl deleting an object that GTK is still trying to use. I assumed the rest of the stack trace was just the crash handler, although it seems quite a coincidence that this bug only appeared in Mageia 7 following an update to libjavascriptcoregtk-4.0 (comment 14). For the record, the next couple of steps look like this: Thread 1 "perl" hit Breakpoint 1, Perl_perly_sighandler (sig=11, sip=0x0, uap=0x0, safe=false) at mg.c:3404 3404 { (gdb) bt #0 Perl_perly_sighandler (sig=11, sip=0x0, uap=0x0, safe=false) at mg.c:3404 #1 0x00007ffff1473f7a in jscSignalHandler() () at /usr/src/debug/webkit2-2.30.4-1.mga8.x86_64/Source/WTF/wtf/threads/Signals.cpp:402 #2 0x00007ffff7aa9580 in <signal handler called> () at /lib64/libc.so.6 #3 emission_find (instance=0x23c6f30, detail=943, signal_id=1) at ../gobject/gsignal.c:893 Maybe libjavascriptcoregtk was silently squashing the faults before.
*** Bug 28008 has been marked as a duplicate of this bug. ***
Info. I can confirm comment 34 and especially 37 . On a fresh install of Mageia 7.1 x64 no problem. I think the seg fault started within the last 3 months.
CC: (none) => kjsimonsen
FWIW as the OP, I've not seen this for a while despite many further reports from others. In particular it doesn't seem to be present on my new install of M8 x86_64-rc Tony
Whiteboard: MGA7TOO => MGA8-rc
Further investigation with a fresh install of Mageia 7.1 with no updates applied. The procedure in comment 37 reliably produces a segfault, but there is no signal handler active, so you only see it by looking in the system log or by running in gdb. The update to webkit2-2.30.4 causes webkit2 to install its own signal handler, which falls back to the Perl signal handler, even though it would appear the Perl signal handler has been deactivated at that point. tl;dr version - the webkit2 update just exposes a fault that was always present but previously went unnoticed.
Whiteboard: MGA8-rc => MGA7TOO
(In reply to Tony Blackwell from comment #45) > FWIW as the OP, I've not seen this for a while despite many further reports > from others. In particular it doesn't seem to be present on my new install > of M8 x86_64-rc Completing mga8 non-free netinstall as I type this. Clicked up an xterm su - root mcc & Software Management->Install & Remove Software (rpmdrake) Once ready did a quit. Used the File pull down to Quit after which received the pop up about do you wish report the problem.
*** Bug 28175 has been marked as a duplicate of this bug. ***
CC: (none) => laan.marc
CC: (none) => fri
*** Bug 28254 has been marked as a duplicate of this bug. ***
CC: (none) => anibal2008365
*** Bug 28261 has been marked as a duplicate of this bug. ***
CC: (none) => c.barbero
So the reason why it was reproducing 100% for me was that I was testing from another (local) machine over ssh -X. I tried a lot of changes but they all caused some BadAccess errors instead. Then I noticed than non crashing drakx tools outside drakconf also generate BadAccess on exit so maybe the workarounds would fix this problem... Testing locally, they all seem to help, for example calling destroy on the window in quit_global in drakconf: gtkset_mousecursor_normal(); $window_global->destroy; standalone::exit(0);
*** Bug 28267 has been marked as a duplicate of this bug. ***
CC: (none) => hosadeeb
*** Bug 28268 has been marked as a duplicate of this bug. ***
CC: (none) => fabio.manunza
I have uploaded drakconf 13.26 to cauldron which should help. If so, we can add the same fix for 7.
(In reply to Pascal Terjan from comment #54) > I have uploaded drakconf 13.26 to cauldron which should help. If so, we can > add the same fix for 7. Updating to drakconf-13.26-1.mga8 on M8 from RC internal take 5, classic ISO x86_64, Plasma. Launching MCC. Run several drak tools. Quit MCC with File => Quit which always SIGSEV (Signal 11) previously and NOW: it is no longer the case! So far so good. MGA8-64-OK. Cauldron considered patched. Please patch M7.
Source RPM: drakconf-13.23-2.mga8 => drakconf-13.23-1.mga7.src.rpmSummary: drakconf segfaulted on exiting MCC => drakconf segfaulted on exiting MCC with File -> QuitStatus comment: drakconf-13.23-1.mga7 => (none)Status: NEW => ASSIGNEDVersion: Cauldron => 7Whiteboard: MGA7TOO => (none)
I have submitted drakconf-13.23.1-1.mga7
Hu(In reply to Pascal Terjan from comment #51) > So the reason why it was reproducing 100% for me was that I was testing from > another (local) machine over ssh -X. Strange, even over ssh, I failed to make it segfault after commenting your destroy call. If you could get a gdb trace, it would be interesting to clone this bug against gtk+3.0 and attach the trace there
I guess that attachment #12183 [details] could be used for that. @Olav, there's a bug in glib/gtk+3.0 that triggers a segfault for some people when exiting mcc. It has been workarounded in comment #51
Funnily by searching for reports of such crash I found https://bugs.mageia.org/show_bug.cgi?id=21167#c23 where I investigated a similar problem in gurpmi 4 years ago and wrote a small reproducer
Working on that reproducer, I found a much simpler one: use Gtk3; Gtk3->init; my $w = Gtk3::Window->new('toplevel'); $::foo = Gtk3::Label->new("foo"); my $continue_button = Gtk3::Button->new("Ok"); $continue_button->signal_connect('parent-set' => sub { exit 0; }); $w->add($continue_button); I guess the problem is likely in the perl Gtk3 binding as that reproducer crashes if there is any global widget (which I guess perl destroys on exit) and exit is called from a signal handler.
Created attachment 12306 [details] backtrace from the small reproducer With the small reproducer I get a short and clean stacktrace showing the problem happens when destroying the global widget (GtkLabel). XS_Glib__Object_DESTROY calls gtk_widget_dispose on the GtkLabel. This calls g_object_unref which calls gtk_widget_dispose which emits a signal (destroy) which causes thing to explode. Thread 1 (Thread 0x7ffff78c5740 (LWP 1684506) "perl"): #0 emission_find (instance=0x14194f0, detail=0, signal_id=53) at ../gobject/gsignal.c:893 #3 0x00007ffff69dee92 in <emit signal ??? on instance 0x14194f0 [GtkLabel]> (instance=instance@entry=0x14194f0, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3550 #1 signal_emit_unlocked_R (node=node@entry=0x1496e50, detail=detail@entry=0, instance=instance@entry=0x14194f0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd810) at ../gobject/gsignal.c:3622 #2 0x00007ffff69dea59 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd998) at ../gobject/gsignal.c:3494 #4 0x00007ffff5ef9590 in gtk_widget_dispose (object=0x14194f0 [GtkLabel]) at gtkwidget.c:12162 #5 0x00007ffff69cbb5f in g_object_unref (_object=<optimized out>) at ../gobject/gobject.c:3465 #6 g_object_unref (_object=0x14194f0) at ../gobject/gobject.c:3395 #7 0x00007ffff6a2c9c3 in XS_Glib__Object_DESTROY (my_perl=<optimized out>, cv=<optimized out>) at GObject.xs:1301 #8 0x00007ffff7d3df47 in Perl_pp_entersub (my_perl=0x4052a0) at pp_hot.c:5277 #9 0x00007ffff7c9b4af in Perl_call_sv (my_perl=my_perl@entry=0x4052a0, sv=<optimized out>, flags=flags@entry=45) at perl.c:3091 #10 0x00007ffff7d41fd3 in S_curse (my_perl=my_perl@entry=0x4052a0, sv=sv@entry=0x1372ae0, check_refcnt=check_refcnt@entry=true) at sv.c:7044 #11 0x00007ffff7d426e8 in Perl_sv_clear (my_perl=my_perl@entry=0x4052a0, orig_sv=orig_sv@entry=0x1372ae0) at sv.c:6641 #12 0x00007ffff7d42c9e in Perl_sv_free2 (my_perl=my_perl@entry=0x4052a0, sv=0x1372ae0, rc=<optimized out>) at sv.c:7145 #13 0x00007ffff7d434e8 in Perl_SvREFCNT_dec_NN (sv=<optimized out>, my_perl=0x4052a0) at inline.h:257 #14 do_clean_objs (ref=0x1367e18, my_perl=0x4052a0) at sv.c:534 #15 S_visit (mask=2048, flags=2048, f=<optimized out>, my_perl=0x4052a0) at sv.c:477 #16 Perl_sv_clean_objs (my_perl=my_perl@entry=0x4052a0) at sv.c:628 #17 0x00007ffff7c9e7d4 in perl_destruct (my_perl=0x4052a0) at perl.c:905 #18 0x0000000000401234 in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at perlmain.c:138
This could be https://rt.cpan.org/Public/Bug/Display.html?id=133428
I opened https://gitlab.gnome.org/GNOME/perl-gtk3/-/issues/8
*** Bug 28316 has been marked as a duplicate of this bug. ***
CC: (none) => jimgarrett001
This will be workarounded with updated packages in core/updates_testing: drakconf-13.23.1-1.mga7.noarch.rpm drakconf-icons-13.23.1-1.mga7.noarch.rpm from drakconf-13.23.1-1.mga7.src.rpm This can be tested. The final corrected fixes will land in a future update ASAP.
*** Bug 28346 has been marked as a duplicate of this bug. ***
CC: (none) => manganeseuk
Assignee: mageiatools => qa-bugs
I installed the drakconf 13.23.1-1 packages from core/updates_testing in a virtual Mga7 and there is no more segfault. Well done!
CC: (none) => sebsweb
Before the update, I checked that I get the drakbug window. I installed the drakconf 13.23.1-1 packages from core/updates_testing in a real Mga7. After that, I repeated the previous operation, but no more drakbug window by quitting mcc.
CC: (none) => yves.brungard_mageia
MGA7-64-OK Suggested Advisory: ======================== Updated drakconf packages fix a segmentation fault bug When user Quit drakconf (Mageia Control Centre) using File => Quit menu, the problem happens when destroying the global widget (GtkLabel). XS_Glib__Object_DESTROY calls gtk_widget_dispose on the GtkLabel. This calls g_object_unref which calls gtk_widget_dispose which emits a signal (destroy) which causes thing to explode. The drakconf package has been patched to fix this issue. References: - https://bugs.mageia.org/show_bug.cgi?id=26944 ======================== Updated packages in core/updates_testing: ======================== drakconf-13.23.1-1.mga7.noarch.rpm drakconf-icons-13.23.1-1.mga7.noarch.rpm from drakconf-13.23.1-1.mga7.src.rpm
Whiteboard: (none) => MGA7-64-OK
I added an advisory to svn
Advisory keyword added as per comment 70. Validating the update.
CC: (none) => sysadmin-bugsKeywords: (none) => advisory, validated_update
7.1/x86_64/media/core/updates/drakconf-13.23.1-1.mga7.noarch.rpm 7.1/x86_64/media/core/updates/drakconf-icons-13.23.1-1.mga7.noarch.rpm but: qa-report mail from 2021-02-13 01:01: Error: Could not move packages and this is still open...
ok looking
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2021-0023.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED
*** Bug 28265 has been marked as a duplicate of this bug. ***
CC: (none) => pealfa