Description of problem: After recent updates something broke mcc. When launching mcc as user the root login appears, the mcc splash screen flashes up and then closes, followed by the opening screen of mcc which closes instantly. Nothing more. Launching drakconf/mcc from a root terminal works. There are error messages in terminal, but these are the same whether it launches or not, so probably unrelated: [root@jackodesktop baz]# drakconf [root@jackodesktop baz]# "/usr/bin/drakmenustyle" is not executable [Menus] at /usr/sbin/drakconf.real line 823. "/usr/sbin/drakbackup" is not executable [Backups] at /usr/sbin/drakconf.real line 823. "/usr/sbin/drakvirt" is not executable [Virtualization] at /usr/sbin/drakconf.real line 823. "/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/sbin/drakconf.real line 823. "/usr/sbin/drakguard" is not executable [Parental Controls] at /usr/sbin/drakconf.real line 823. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
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
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)Source RPM: drakconf-12.38-1.mga3.src.rpm => glib2.0-2.36.2-1.mga4, drakconf-12.38-1.mga3.src.rpm
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
*** Bug 10472 has been marked as a duplicate of this bug. ***
CC: (none) => ftg
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, olavSource RPM: glib2.0-2.36.2-1.mga4, drakconf-12.38-1.mga3.src.rpm => glib2.0-2.36.2-1.mga4, drakconf-12.38-1.mga3.src.rpm, webkit
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!
CC: (none) => marcello.anni
*** Bug 11959 has been marked as a duplicate of this bug. ***
CC: (none) => lewyssmith
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.
Priority: Normal => release_blockerHardware: x86_64 => AllWhiteboard: (none) => Mageia 4 beta 2
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!
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 => RESOLVEDResolution: (none) => FIXED
*** Bug 11417 has been marked as a duplicate of this bug. ***
CC: (none) => nikos569
*** Bug 11870 has been marked as a duplicate of this bug. ***
CC: (none) => pf
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
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
*** Bug 12132 has been marked as a duplicate of this bug. ***
CC: (none) => 4d6b499b
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 => RESOLVEDResolution: (none) => FIXED
*** Bug 12149 has been marked as a duplicate of this bug. ***
CC: (none) => info
Still one report...
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)
See bug 12034 comment 20
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 210
CC: (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
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
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
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'
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
Blocks: (none) => 11492
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