| Summary: | MCC & mgapplet segfault due to glib2.0/webkit threads (perl segfaulting when having a custom signal handler for SIG_CHILD) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Barry Jackson <zen25000> |
| Component: | RPM Packages | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | release_blocker | CC: | 4d6b499b, carlos_mac, ennael1, fri, ftg, fundawang, gruescubogdan, hhielscher, info, jquelin, lewyssmith, linux, mageia, marcello.anni, nikos769, olav, pf, philippe.flat, shlomif, tarakbumba |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://rt.perl.org/Ticket/Display.html?id=120951 | ||
| Whiteboard: | Mageia 4 beta 2 | ||
| Source RPM: | glib2.0-2.36.2-1.mga4, perl, drakconf-12.38-1.mga3.src.rpm | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 9102, 11492 | ||
| Attachments: |
GDB trace with symbols
workaround thie issue workaround the issue reliably make mcc to segfault on startup GDB trace of mgaaplet's segfault by Colin workaround: kill the regular wakup, only rely on SIG{CHLD bug reproducer |
||
|
Description
Barry Jackson
2013-05-26 11:01:53 CEST
yes they are unrelated, I suspect a duplicate of this one: https://bugs.mageia.org/show_bug.cgi?id=4136 ah you are on cauldron sorry, so maybe more the gtk and co updates Assignee:
bugsquad =>
thierry.vignaud
Thierry Vignaud
2013-05-26 21:36:24 CEST
Summary:
MCC fails to start as usr (after auth) =>
MCC fails to start as user (after auth) It segfaults in glib2.0 (which was updated last week) Summary:
MCC fails to start as user (after auth) =>
MCC segfaults in glib2.0 (after auth)
Helge Hielscher
2013-06-06 19:01:27 CEST
CC:
(none) =>
hhielscher (In reply to Thierry Vignaud from comment #3) I don't think so. I have had very same issue until today. I had installed tainted packages. Today i removed them and installed available ones from core. Problem disappeaed. List of tainted ones are: lib64swscaler2 lib64txc-dxtn lib64mesaegl1 lib64avutil52 lib64mesaopenvg1 lib64faad2 gstreamer0.10-voip lib64x264_125 lib64llvmradeon9.1.3 lib64gbm1 lib64dca0 mplayer lib64vo-amrwbenc0 lib64avcodec54 lib64swresample0 lib64dri-drivers lib64lame0 lib64postproc52 mesa lib64rtmp0 lib64avfilter3 lib64freetype6 lib64xvid4 lib64vo-aacenc0 lib64avformat54 lib64dricore1 lib64mesaglesv2_2 lib64dvdcss2 lib64glapi0 lib64mesagl1 So, i suspect from freetype6, wdt? CC:
(none) =>
tarakbumba (In reply to Atilla ÃNTAÅ from comment #4) Nah. Wrong solution. Somehow drakconf worked for a session like it should do. But after logout-logback in bug returned. So, we need to fix for glib2.0 Just in case this might help you: on a cauldron installation performed about a week ago (network install) and updated since then MCC opens fine without any issue, but a different system updated to Cauldron from Mageia 3 have this bug (exhibit this issue as described by Barry). In short: new installations might not be affected. CC:
(none) =>
gruescubogdan (In reply to Bogdan Gruescu from comment #7) > Just in case this might help you: on a cauldron installation performed about > a week ago (network install) and updated since then MCC opens fine without > any issue, but a different system updated to Cauldron from Mageia 3 have > this bug (exhibit this issue as described by Barry). In short: new > installations might not be affected. Possibly - my cauldron is a continuing installation from pre-Mga3. My cauldron is a clean net-install on May 15th and I have not experienced this bug, which supports the speculation in comment#7. I had the trouble with an MGA3 updated to Cauldron + others troubles. I have done a new install (keeping home but new user and same root password) and I have still the trouble with MCC. CC:
(none) =>
philippe.flat glib2.0 was updated today on Cauldron and the problem remains. Curiously, one time out of ten (or more), MCC works. (!) I think this has something to do with authentication, as callinc mcc from the terminal as a normal user, it asks for the root password, loads and disappears (crashes). I haven't found any log that gives relevant information of what is happening. As su, it works. CC:
(none) =>
carlos_mac No, it just depends on whether glib see it needed or not to run dbus-launcher & the like (depending of env variables) CC:
(none) =>
fundawang, jquelin, mageia, olav And indeed it doesn't segfault when DBUS_SESSION_BUS_ADDRESS is not filetered out by sudo/su, thus preventing glib to fork Created attachment 4145 [details]
GDB trace with symbols
For what it's worth, if someone fancies looking into this further, I think it would be good to ditch the current consolehelper/su based system and instead switch to something based on polkit. This basically means writing policy files for all our tools currently using consolehelper and moving the binaries around a bit (I'd very much like to avoid a /usr/bin/mytool script running /usr/sbin/mytool "binary" - better to move it to /usr/lib/<pkg>/<app> and put the wrapper script in /usr/bin/mytool. I've documented the change here along with an example: https://wiki.mageia.org/en/Feature:SystemdTidyups#consolehelper.2Fuserhelper_vs._polkit However, with that said, it seems doing this does not actually fix the problem anyway!! So, this is a rather pointless comment, but as I'd already written it you're getting subjected to it anyway!! (In reply to Thierry Vignaud from comment #14) > Created attachment 4145 [details] > GDB trace with symbols FWIW, I get a slightly different backtrace (namely in step 4): (gdb) bt #0 0x00007f419dd0c92a in Perl_csighandler () from /usr/lib/perl5/5.18.0/x86_64-linux-thread-multi/CORE/libperl.so #1 <signal handler called> #2 0x00007f419dd0c8f2 in Perl_csighandler () from /usr/lib/perl5/5.18.0/x86_64-linux-thread-multi/CORE/libperl.so #3 <signal handler called> #4 0x0000003614ce7ca3 in select () from /lib64/libc.so.6 #5 0x00007f419b150457 in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0, flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0, standard_output=standard_output@entry=0x7f413fffebf0, standard_error=standard_error@entry=0x7f413fffebf8, exit_status=exit_status@entry=0x7f413fffebec, error=error@entry=0x7f413fffec58) at gspawn.c:328 #6 0x00007f419b150aa8 in g_spawn_command_line_sync (command_line=command_line@entry=0x7f4138003d00 "dbus-launch --autolaunch=6cb2a4b2bd6df042e57da8a4000001d4 --binary-syntax --close-stderr", Looking at the log here: https://git.gnome.org/browse/glib/log/glib/gspawn.c?id=2.37.2 A likely commit is: https://git.gnome.org/browse/glib/commit/glib/gspawn.c?id=eb860fd898a6a2bd86c11d245294cd0e8cd4304b So that's where I'm pointing the finger at present. It's already in latest glib2.0 Created attachment 4146 [details]
workaround thie issue
This workaround the issue but we'd better fix glib for real
Great news, I've just updated my Mageia and MCC is working again. Thanks, all!
Marcello Anni
2013-06-25 11:45:48 CEST
CC:
(none) =>
marcello.anni Throughout recent (beta) Mageia 4 pre-release testing, Mageia Control Centre *has not worked*. This was noted in the PAD. Simply, MCC does not work to varying degrees with most M4 desktops. Testing a Dec 9 2013 beta3 Classic DVD installation with 5 desktops - brought up-to-date 11 Dec - I offer the following precisions. In fact the picture has got better. GNOME: Whether from icon or terminal, the pop-up root password dialogue bounces that (correct) password, so MCC cannot be launched. If this is by-passed by 'mcc' from a root terminal, it starts & disappears as for other desktops below. KDE: Both from icon/menu or terminal, after accepting the root password, MCC starts up and immediately dies. Console O/P:- $ mcc [graphic root p/w dialogue] LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. "/usr/sbin/drakmenustyle" is not executable [Menus] at /usr/libexec/drakconf line 823. "/usr/sbin/drakbackup" is not executable [Backups] at /usr/libexec/drakconf line 823. "/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/libexec/drakconf line 823. "/usr/sbin/drakguard" is not executable [Parental Controls] at /usr/libexec/drakconf line 823. java version "1.7.0_45" OpenJDK Runtime Environment (mageia-2.4.3.2.mga4-i386 u45-b15) OpenJDK Client VM (build 24.45-b08, mixed mode, sharing) Segmentation fault LXDE: From icon/menu, nothing at all happens - no root password dialogue. 'mcc' from terminal asks for root p/w (in terminal, not graphic dialogue box), MCC appears then dies immediately with the same errors as above. MATE: From icon/menu - WORKS! I think this is very recent. From terminal, WORKS also, but with errors as above but *no* crash. XFCE: From icon/menu, asks for root password then *works*; again I think this is very recent. From terminal (root p/w input is from console), it gives the console errors noted above, *works* sometimes, no crash; or *crashes*. Almost alternately. Version-Release number of selected component (if applicable): Mageia4 Betas (from Classic 32-bit DVD). 9 Dec 2013 system updated 11th. How reproducible: See description above. A bit of a moving target, but consistent at any one time.
Lewis Smith
2013-12-12 20:19:34 CET
Priority:
Normal =>
release_blocker It only happens on some machines, depending on machine speed, due to glib creating threads behind our back... Thierry re comment 22 My box is single-processor, so would threads be relevant? BTAIM It would be nice if the bug title could be amended to mention MCC. In my view this problem *has* to be sorted: one cannot let out Mageia knowing that MCC is so vulnerable, it being such a major component. I know that Claire also reported the issue. Add to Comment 22: I use real 32-bit hardware, with SiS on-board basic video. CINNAMON: The MCC icon does nothing. But MCC *works* from terminal. I alone have another (but very consistent in Mag4 testing) problem re MCC authorisation dialogue under GNOME: it always refuses the root password. Other people do not have this, nor the crashes. Could this be a related problem, or shall I raise a different bug for it? Below are separate problems unrelated to this bug. (In reply to Lewis Smith from comment #23) > CINNAMON: The MCC icon does nothing. But MCC *works* from terminal. Likely double forking while launching. I've fixed various DEs for this, likely cinnamon is still broken. It's maintainer should patch it accordingly. See my mega rant on the topic: https://plus.google.com/105465824670275586186/posts/CTHHhVUnz8H > I alone have another (but very consistent in Mag4 testing) problem re MCC > authorisation dialogue under GNOME: it always refuses the root password. > Other people do not have this, nor the crashes. Could this be a related > problem, or shall I raise a different bug for it? Likely due to having a user in the wheel group in that setup and it's asking for that *users* password not the root one. Check carefully that it's really asking for the root user's password. But as these are separate, please don't comment further on this bug about these!
psyca
2013-12-15 00:25:14 CET
CC:
(none) =>
fx commit 47a68aeb88db40da6927ce9bfb92e25c93d3719b
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Sat Dec 21 04:10:36 2013 +0100
fix segfault when WebKit creates threads for good (mga#10289)
ignore SIGCHLD until WebKit has finished creating its threads
---
Commit Link:
http://gitweb.mageia.org/software/control-center/commit/?id=47a68aeb88db40da6927ce9bfb92e25c93d3719b
Fixed Status:
NEW =>
RESOLVED
Thierry Vignaud
2013-12-27 15:31:42 CET
Status:
RESOLVED =>
REOPENED Created attachment 4669 [details]
workaround the issue
For those who still can reproduce this issue (I can only reproduce it once in 100 runs...):
does this patch helps?
Attachment 4146 is obsolete:
0 =>
1 commit d4afbe1de7a5fc9bbe88e478257b582d98f64a79
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Sat Dec 28 16:38:14 2013 +0100
try harder to prevent segfaulting on webkit init (mga#10289)
we segfault in SIG_CHLD when temporary webkit threads exit on init:
delay setting CHLD handler on forking the 1st tool
---
Commit Link:
http://gitweb.mageia.org/software/control-center/commit/?id=d4afbe1de7a5fc9bbe88e478257b582d98f64a79
Closing for now Please reopen if you can still reproduce with drakconf-12.47-1.mga4 Status:
REOPENED =>
RESOLVED Still one report... Status:
RESOLVED =>
REOPENED Just upgraded -- now mcc won't start and I get this: # mcc Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.PolicyKit1 timed out That's a totally separated issue (not a mcc one but one of your polkit agent) As already pointed, that has _nothing_ to do with this bug So what about this bug? Ifthis has nothing to do with this bug please close it CC:
(none) =>
ennael1 The polkit issue has nothing to do but there's still an issue.
Interestingly, the first report came just after we upgrade from glib-2.34 to 2.36 (and prior to the update from perl-5.16 to 5.18)
I've workarounded this in mcc by setting SIG{CHLD} later.
See the 6 commits related to #10289 in http://gitweb.mageia.org/software/control-center/log/control-center
I can make mcc to reliably segfault by setting SIG{CHLD} earlier (by moving "$SIG{CHLD} =..." at top of /usr/libexec/drakconf)
Basically, we segfault in SIG_CHLD when webkit threads exit (webkit creates temporary ones on init).
Delaying setting CHLD handler workaround this...
However now Colin is reporting the same bug with mgaapplet.
So, as far as I'm concerned there's 2 bugs:
- glib & webkit creating threads behind our back
(=> Olav)
- perl segfaulting when having a custom signal handler for SIG_CHILD
(=> Jerome & Shlomif)
There was an old bug that got fixed in perl-5.10.0:
https://rt.perl.org/Public/Bug/Display.html?id=60724
https://access.redhat.com/site/solutions/425043 ("Segfault in perl Perl_csighndler when custom signal handler installed")
It looks like a variant of this bug is happening b/c of glib's & webkit's threads.
I could disable the sig_child handlers (which did caused problems back around 210CC:
(none) =>
shlomif Created attachment 4722 [details]
reliably make mcc to segfault on startup
Created attachment 4723 [details]
GDB trace of mgaaplet's segfault by Colin
Thierry Vignaud
2014-01-06 04:10:55 CET
Summary:
MCC segfaults in glib2.0 (after auth) =>
MCC & mgapplet segfault due to glib2.0/webkit threads (perl segfaulting when having a custom signal handler for SIG_CHILD) It looks like we could disable our custom signal handler in mcc. There're no more zombie processes (was needed back in 2004). Note that beside mcc & mgaapplet, other tools have custom signal handlers, notably net_applet. It had the same issues about zombie processes (reported in 2006 & fixed in 2009). See: https://qa.mandriva.com/show_bug.cgi?id=20552 http://gitweb.mageia.org/software/drakx-net/commit/?id=4742d2ef48320cf3fb2ca47aabb3dd4180804d42 http://gitweb.mageia.org/software/drakx-net/commit/?id=db7b8c3833c1af1bdbfeaddfcd6680278c557704 http://gitweb.mageia.org/software/drakx-net/commit/?id=a09384d14365fc46eb8c91b0173bb5de824875f6
Thierry Vignaud
2014-01-06 04:38:05 CET
Source RPM:
glib2.0-2.36.2-1.mga4, drakconf-12.38-1.mga3.src.rpm, webkit =>
glib2.0-2.36.2-1.mga4, perl, drakconf-12.38-1.mga3.src.rpm, webkit It this the same? Just upgraded two mga4 64 bit and i get on both: # mcc LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. "/usr/sbin/drakmenustyle" is not executable [Menus] at /usr/libexec/drakconf line 832. "/usr/sbin/drakbackup" is not executable [Backups] at /usr/libexec/drakconf line 832. "/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/libexec/drakconf line 832. "/usr/sbin/drakguard" is not executable [Parental Controls] at /usr/libexec/drakconf line 832. Segmenteringsfel [root@T61M Hämtningar]# java version "1.7.0_45" OpenJDK Runtime Environment (mageia-2.4.3.3.mga4-x86_64 u45-b15) OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 296. I can start drakrpm, diskdrake etc separately. CC:
(none) =>
fri I experiment the same error as Morgan on mg4 64bit (In reply to Morgan Leijström from comment #44) > It this the same? > Just upgraded two mga4 64 bit and i get on both: Yes Created attachment 4732 [details]
workaround: kill the regular wakup, only rely on SIG{CHLD
Can those who still see this bug with as of drakconf-12.48 try this workaround?
as root, just run this command in a terminal:
cd /; patch -p0 < /where/it/was/downloaded/10289-kill-wakup.diff
# drakconf --version Drakxtools version 16.18 Copyright (C) 1999-2008 Mandriva by <install@mandriva.com> 16.18? Mandriva? anyway: ]# cd /; patch -p0 < /home/sparas/Hämtningar/10289-kill-wakup.diff patching file /usr/libexec/drakconf [root@T61M /]# mcc LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589. LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589. "/usr/sbin/drakmenustyle" is not executable [Menus] at /usr/libexec/drakconf line 831. "/usr/sbin/drakbackup" is not executable [Backups] at /usr/libexec/drakconf line 831. "/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/libexec/drakconf line 831. "/usr/sbin/drakguard" is not executable [Parental Controls] at /usr/libexec/drakconf line 831. java version "1.7.0_45" OpenJDK Runtime Environment (mageia-2.4.3.5.mga4-x86_64 u45-b15) OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) Segmenteringsfel [root@T61M /]# Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 296. Use "rpm -q drakconf" in order to get the version. Did you apply the patch? Ah, thanks; rpm -q drakconf drakconf-12.48-1.mga4 Downloaded 10289-kill-wakup.diff and used the command you gave, and run mcc, see my post. Its main window shortly shows up, then dissapears directly, while the log window still is shown. I then close the log window. commit 9b4e9da3dabd58573cc2c941bed524fc1fb24f7b
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Tue Jan 7 14:46:08 2014 +0100
delay starting up logdrake, thus fixing segfault on startup (mga#10289)
we would segfault when "Display Logs" option is set
---
Commit Link:
http://gitweb.mageia.org/software/control-center/commit/?id=9b4e9da3dabd58573cc2c941bed524fc1fb24f7b
Indeed with that option, it caused a segfault. Please try again drakconf-12.49 once it reachs your favorite mirror (w/o the patch first) Note that I accidently commited attachment #4732 [details] btw.
As it seems to have no side effects regarding zombie processes, I'll not revert that bit
confirming - fixes startig mcc for me, fully updated mga4 x86_64 KDE :) commit 264e9201b28e330594b581ce1649b744c8c10036
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Tue Jan 7 13:13:35 2014 +0100
display mga copyright too (mga#10289)
---
Commit Link:
http://gitweb.mageia.org/software/drakx/commit/?id=264e9201b28e330594b581ce1649b744c8c10036
Thierry Vignaud
2014-01-07 23:24:50 CET
Source RPM:
glib2.0-2.36.2-1.mga4, perl, drakconf-12.38-1.mga3.src.rpm, webkit =>
glib2.0-2.36.2-1.mga4, perl, drakconf-12.38-1.mga3.src.rpm Can anyone reproduce this bug with mcc? Keywords:
(none) =>
NEEDINFO Created attachment 4738 [details]
bug reproducer
Olav, Jerome & Shlomif, here's a reproducer involving only 35 lines of perl using std modules
Whereas the bug is workarounded for mcc, it would still be good to fix it for good...
Jerome, Shlomif; the following one liner does it too:
perl -MGtk2 -MGtk2::WebKit -e '$SIG{CHLD} = sub { warn }; Gtk2->init; my $wiew = Gtk2::WebKit::WebView->new; $w=Gtk2::Window->new; $w->add($view); Gtk2->main'
Thierry Vignaud
2014-01-08 01:07:15 CET
URL:
(none) =>
https://rt.perl.org/Ticket/Display.html?id=120951 Hi Thierry, (In reply to Thierry Vignaud from comment #57) > Created attachment 4738 [details] > bug reproducer > > Olav, Jerome & Shlomif, here's a reproducer involving only 35 lines of perl > using std modules > > Whereas the bug is workarounded for mcc, it would still be good to fix it > for good... Sure, but I am unable to reproduce it here: <SHELL> shlomif@telaviv1:~$ which perl /usr/bin/perl shlomif@telaviv1:~$ perldoc -l Gtk2 /usr/lib/perl5/vendor_perl/5.18.1/x86_64-linux-thread-multi/Gtk2.pm shlomif@telaviv1:~$ perldoc -l Gtk2::WebKit /usr/lib/perl5/vendor_perl/5.18.1/x86_64-linux-thread-multi/Gtk2/WebKit.pod shlomif@telaviv1:~$ perldoc -l POSIX /usr/lib/perl5/5.18.1/x86_64-linux-thread-multi/POSIX.pod shlomif@telaviv1:~$ shlomif@telaviv1:~$ shlomif@telaviv1:~$ shlomif@telaviv1:~$ shlomif@telaviv1:~$ shlomif@telaviv1:~$ shlomif@telaviv1:~$ shlomif@telaviv1:~$ perl mcc.bin >> HERE1 >> HERE2 shlomif@telaviv1:~$ </SHELL> And I am able to press the link and it prompts me to try again. I'm using Cauldron with kernel 3.12.6-desktop-4.mga4 on x86-64 with KDE 4 on a Core i3 machine with Intel Graphics HD. How can I reliably reproduce the bug? Regards, -- Shlomi Fish Oh, I see "perl mcc.bin" reliably segfaults as root:
<SHELL>
root@telaviv1:/home/shlomif$ perl mcc.bin
>> HERE1
Segmentation fault
</SHELL>
Note that I opened a bug report upstream at https://rt.perl.org/Ticket/Display.html?id=120951&results=3ec8513c53e396e8de7f391d51cffca9 Can I leave it to you now? commit ba9e231906396de7c7a16d52474b9a7524baea07
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Wed Jan 8 04:10:26 2014 +0100
better fix for segfault on startup (mga#10289)
just block the CHLD signal during the window where glib/webkit create
threads behind our back (RT-120951)
---
Commit Link:
http://gitweb.mageia.org/software/control-center/commit/?id=ba9e231906396de7c7a16d52474b9a7524baea07
commit 3d84feede672609e1c490af4a6d69c14f07ba7fa
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Wed Jan 8 04:42:00 2014 +0100
delay setting SIG_CHLD handler (mga#10289)
thus fixing segfault on startup
---
Commit Link:
http://gitweb.mageia.org/software/mgaonline/commit/?id=3d84feede672609e1c490af4a6d69c14f07ba7fa
commit 571aeab77c9d52375d061f53a729b3910f40e876
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Wed Jan 8 04:47:58 2014 +0100
delay setting SIG_CHLD handler
thus preventing potential segfault on startup (mga#10289)
---
Commit Link:
http://gitweb.mageia.org/software/drakx-net/commit/?id=571aeab77c9d52375d061f53a729b3910f40e876
Thierry Vignaud
2014-01-08 05:00:29 CET
Blocks:
(none) =>
11492
Thierry Vignaud
2014-01-08 05:04:18 CET
Blocks:
(none) =>
9102 Testing recent (Jan 2014) Mag4 RC Classic installs on 32bit hardware, I have noted & reported that MCC now *works* from all desktops (except Razor, only just tried) from taskbar icons or menus (except my private Gnome authentification failure - seperate bug). Does this bug need to remain open? mgaaplet is still affected, Colin is testing a patch Sadly it doesn't seem to work. Not got a helpful backtrace yet tho' :( commit 4ec5b7cec36a3435e970022d4542ac2158dd6d2b
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Wed Jan 22 21:07:47 2014 +0100
block CHLD signals on startup
in order to prevent glib-threading segfaults (mga#10289), just block the
CHLD signal during the window where glib create threads behind our back
(RT-120951)
---
Commit Link:
http://gitweb.mageia.org/software/mgaonline/commit/?id=4ec5b7cec36a3435e970022d4542ac2158dd6d2b
Fixed in last isos Status:
REOPENED =>
RESOLVED |