Bug 26944 - drakconf segfaulted on exiting MCC
Summary: drakconf segfaulted on exiting MCC
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High major
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard: MGA7TOO
Keywords:
: 27014 27015 27078 27448 27451 27708 27718 27743 27754 27768 27770 27799 27801 27812 27813 27924 27991 28008 28009 28016 28175 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-13 12:23 CEST by Tony Blackwell
Modified: 2021-01-23 18:21 CET (History)
25 users (show)

See Also:
Source RPM: drakconf-13.23-2.mga8
CVE:
Status comment: drakconf-13.23-1.mga7


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

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.

Priority: Normal => High
Summary: drakconf segfaulted => drakconf segfaulted on exiting MCC

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.

CC: lewyssmith => (none)
Severity: minor => major

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


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