Bug 26944 - drakconf segfaulted on exiting MCC with File -> Quit
Summary: drakconf segfaulted on exiting MCC with File -> Quit
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: x86_64 Linux
Priority: High major
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
: 27014 27015 27078 27448 27451 27708 27718 27743 27754 27768 27770 27799 27801 27812 27813 27924 27991 28008 28009 28016 28175 28254 28261 28265 28267 28268 28316 28346 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-13 12:23 CEST by Tony Blackwell
Modified: 2021-02-19 15:20 CET (History)
37 users (show)

See Also:
Source RPM: drakconf-13.23-1.mga7.src.rpm
CVE:
Status comment:


Attachments
2021_01_05_drakconf_segfault_lspcidrake-v.txt (14.25 KB, text/plain)
2021-01-05 13:49 CET, Paul Blackburn
Details
strace-mcc-sigsegv on exiting (270.86 KB, text/plain)
2021-01-05 17:56 CET, Aurelien Oudelet
Details
full backtrace from segfault (4.36 KB, text/plain)
2021-01-05 19:57 CET, Martin Whitaker
Details
backtrace from the small reproducer (7.63 KB, text/plain)
2021-02-03 21:40 CET, Pascal Terjan
Details

Description Tony Blackwell 2020-07-13 12:23:12 CEST
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
Comment 1 Lewis Smith 2020-07-17 21:59:50 CEST
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) => lewyssmith
Assignee: bugsquad => mageiatools

Comment 2 Lewis Smith 2020-07-29 21:13:18 CEST
*** Bug 27014 has been marked as a duplicate of this bug. ***

CC: (none) => jeevanism

Comment 3 Lewis Smith 2020-07-29 21:20:36 CEST
*** Bug 27015 has been marked as a duplicate of this bug. ***

CC: (none) => tarazed25

Olav Vitters 2020-07-29 21:59:37 CEST

CC: (none) => olav

Comment 4 Tony Blackwell 2020-07-30 10:10:11 CEST
Despite the way I initially presented this, I think it just segfaults on MCC exit.
Tony
Comment 5 Bit Twister 2020-07-31 06:22:52 CEST
(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

Comment 6 Dave Hodgins 2020-07-31 07:10:48 CEST
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

Comment 7 Bit Twister 2020-07-31 12:49:25 CEST
(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.
Comment 8 Dave Hodgins 2020-07-31 13:21:37 CEST
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.
Comment 9 Martin Whitaker 2020-08-14 12:02:47 CEST
*** Bug 27078 has been marked as a duplicate of this bug. ***

CC: (none) => pleny29

Comment 10 Martin Whitaker 2020-10-19 19:14:44 CEST
*** Bug 27451 has been marked as a duplicate of this bug. ***

CC: (none) => jm.sarat

Comment 11 Lewis Smith 2020-12-02 21:28:23 CET
*** Bug 27448 has been marked as a duplicate of this bug. ***
Comment 12 Lewis Smith 2020-12-02 21:30:54 CET
*** Bug 27708 has been marked as a duplicate of this bug. ***

CC: (none) => amaranthine.technology

Comment 13 Lewis Smith 2020-12-02 21:33:21 CET
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 MCC
Priority: Normal => High

Comment 14 Martin Whitaker 2020-12-03 12:19:24 CET
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

Comment 15 Aurelien Oudelet 2020-12-07 10:13:47 CET
*** Bug 27743 has been marked as a duplicate of this bug. ***

CC: (none) => pi.astra

Comment 16 Aurelien Oudelet 2020-12-07 10:14:09 CET
*** Bug 27754 has been marked as a duplicate of this bug. ***

CC: (none) => gillou260

Comment 17 Aurelien Oudelet 2020-12-07 10:15:01 CET
*** Bug 27763 has been marked as a duplicate of this bug. ***

CC: (none) => daniel.monsegu

Comment 18 Aurelien Oudelet 2020-12-07 10:15:26 CET
*** Bug 27768 has been marked as a duplicate of this bug. ***
Comment 19 Aurelien Oudelet 2020-12-07 10:16:09 CET
*** Bug 27770 has been marked as a duplicate of this bug. ***

CC: (none) => domisse

Comment 20 Aurelien Oudelet 2020-12-07 10:18:36 CET
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

Aurelien Oudelet 2020-12-07 10:19:24 CET

Status comment: (none) => drakconf-13.23-1.mga7
Whiteboard: (none) => MGA7TOO

Comment 21 Aurelien Oudelet 2020-12-07 10:27:10 CET
*** Bug 27718 has been marked as a duplicate of this bug. ***

CC: (none) => codebuddy

Comment 22 Lewis Smith 2020-12-07 10:31:28 CET
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 => major
CC: lewyssmith => (none)

Comment 23 Thierry Vignaud 2020-12-07 15:10:38 CET
I fail to reproduce that (at least on Cauldron)

CC: (none) => thierry.vignaud

Comment 24 Aurelien Oudelet 2020-12-10 19:21:19 CET
*** Bug 27799 has been marked as a duplicate of this bug. ***

CC: (none) => ruben33en-mandriva

Comment 25 Aurelien Oudelet 2020-12-11 16:09:41 CET
*** Bug 27801 has been marked as a duplicate of this bug. ***

CC: (none) => vbcoen

Comment 26 Aurelien Oudelet 2020-12-14 10:08:26 CET
*** Bug 27813 has been marked as a duplicate of this bug. ***

CC: (none) => paul.blackburn

Comment 27 Aurelien Oudelet 2020-12-14 10:09:24 CET
*** Bug 27812 has been marked as a duplicate of this bug. ***
Comment 28 Aurelien Oudelet 2020-12-24 18:42:20 CET
*** Bug 27924 has been marked as a duplicate of this bug. ***

CC: (none) => zeheron

Comment 29 Aurelien Oudelet 2020-12-31 06:42:09 CET
*** Bug 27991 has been marked as a duplicate of this bug. ***

CC: (none) => johnms

Comment 30 Martin Whitaker 2021-01-03 12:39:47 CET
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?
Comment 31 Aurelien Oudelet 2021-01-03 12:48:56 CET
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
Comment 32 Aurelien Oudelet 2021-01-03 21:20:03 CET
*** Bug 28009 has been marked as a duplicate of this bug. ***

CC: (none) => jneri

Comment 33 Aurelien Oudelet 2021-01-05 13:01:26 CET
*** Bug 28016 has been marked as a duplicate of this bug. ***
Comment 34 Paul Blackburn 2021-01-05 13:47:58 CET
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'.
Comment 35 Paul Blackburn 2021-01-05 13:49:00 CET
Created attachment 12181 [details]
2021_01_05_drakconf_segfault_lspcidrake-v.txt

Output from 'lspcidrake -v' after drakconf segfault.
Comment 36 Aurelien Oudelet 2021-01-05 17:56:26 CET
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
Comment 37 Martin Whitaker 2021-01-05 19:57:16 CET
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.
Comment 38 Aurelien Oudelet 2021-01-05 20:01:59 CET
@Martin, how you obtain it?
Comment 39 Martin Whitaker 2021-01-05 20:41:52 CET
(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
Comment 40 Pascal Terjan 2021-01-05 21:14:18 CET
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.
Comment 41 Pascal Terjan 2021-01-05 21:30:45 CET
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

Comment 42 Martin Whitaker 2021-01-05 21:31:30 CET
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.
Comment 43 Aurelien Oudelet 2021-01-07 22:54:26 CET
*** Bug 28008 has been marked as a duplicate of this bug. ***
Comment 44 Karl Johan Simonsen 2021-01-09 11:43:00 CET
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

Comment 45 Tony Blackwell 2021-01-09 23:05:37 CET
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

Comment 46 Martin Whitaker 2021-01-09 23:56:43 CET
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

Comment 47 Bit Twister 2021-01-10 00:44:53 CET
(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.
Comment 48 Aurelien Oudelet 2021-01-23 18:21:57 CET
*** Bug 28175 has been marked as a duplicate of this bug. ***

CC: (none) => laan.marc

Morgan Leijström 2021-01-26 21:16:20 CET

CC: (none) => fri

Comment 49 Lewis Smith 2021-01-30 17:03:43 CET
*** Bug 28254 has been marked as a duplicate of this bug. ***

CC: (none) => anibal2008365

Comment 50 Lewis Smith 2021-01-31 21:01:08 CET
*** Bug 28261 has been marked as a duplicate of this bug. ***

CC: (none) => c.barbero

Comment 51 Pascal Terjan 2021-01-31 23:49:56 CET
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);
Comment 52 Lewis Smith 2021-02-01 10:03:38 CET
*** Bug 28267 has been marked as a duplicate of this bug. ***

CC: (none) => hosadeeb

Comment 53 Aurelien Oudelet 2021-02-01 13:58:28 CET
*** Bug 28268 has been marked as a duplicate of this bug. ***

CC: (none) => fabio.manunza

Comment 54 Pascal Terjan 2021-02-01 21:25:03 CET
I have uploaded drakconf 13.26 to cauldron which should help. If so, we can add the same fix for 7.
Comment 55 Aurelien Oudelet 2021-02-02 16:05:05 CET
(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.rpm
Summary: drakconf segfaulted on exiting MCC => drakconf segfaulted on exiting MCC with File -> Quit
Status comment: drakconf-13.23-1.mga7 => (none)
Status: NEW => ASSIGNED
Version: Cauldron => 7
Whiteboard: MGA7TOO => (none)

Comment 56 Pascal Terjan 2021-02-02 23:17:30 CET
I have submitted drakconf-13.23.1-1.mga7
Comment 57 Thierry Vignaud 2021-02-03 17:20:09 CET
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
Comment 58 Thierry Vignaud 2021-02-03 17:25:39 CET
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
Comment 59 Pascal Terjan 2021-02-03 18:14:36 CET
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
Comment 60 Pascal Terjan 2021-02-03 18:26:07 CET
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.
Comment 61 Pascal Terjan 2021-02-03 21:40:07 CET
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
Comment 62 Pascal Terjan 2021-02-03 22:01:29 CET
This could be https://rt.cpan.org/Public/Bug/Display.html?id=133428
Comment 63 Pascal Terjan 2021-02-03 22:08:44 CET
I opened https://gitlab.gnome.org/GNOME/perl-gtk3/-/issues/8
Comment 64 Aurelien Oudelet 2021-02-07 23:51:06 CET
*** Bug 28316 has been marked as a duplicate of this bug. ***

CC: (none) => jimgarrett001

Comment 65 Aurelien Oudelet 2021-02-07 23:54:47 CET
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.
Comment 66 Aurelien Oudelet 2021-02-11 15:35:32 CET
*** Bug 28346 has been marked as a duplicate of this bug. ***

CC: (none) => manganeseuk

Pascal Terjan 2021-02-11 16:06:05 CET

Assignee: mageiatools => qa-bugs

Comment 67 Sébastien Morin 2021-02-11 16:31:14 CET
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

Comment 68 papoteur 2021-02-11 16:39:01 CET
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

Comment 69 Aurelien Oudelet 2021-02-11 17:41:51 CET
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

Comment 70 Pascal Terjan 2021-02-11 21:20:33 CET
I added an advisory to svn
Comment 71 Dave Hodgins 2021-02-12 22:29:39 CET
Advisory keyword added as per comment 70.

Validating the update.

CC: (none) => sysadmin-bugs
Keywords: (none) => advisory, validated_update

Comment 72 Aurelien Oudelet 2021-02-13 15:13:21 CET
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...
Comment 73 Nicolas Lécureuil 2021-02-13 15:31:50 CET
ok looking

CC: (none) => mageia

Comment 74 Mageia Robot 2021-02-13 16:32:15 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2021-0023.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED

Comment 75 Aurelien Oudelet 2021-02-19 15:20:28 CET
*** Bug 28265 has been marked as a duplicate of this bug. ***

CC: (none) => pealfa


Note You need to log in before you can comment on or make changes to this bug.