Description of problem: MGA9-32 Xfce on an HP Probook 6550b, i3, Intel graphics, currently using the server kernel, but with all other 32-bit kernel flavors installed. (All four 32-bit kernels are installed because I sometimes use this install as a test bed for them.) This particular install had not been used in a month or so, and I booted into it and got updates using drakconf, including glibc, the 4 kernels, drakconf and icons, and webkit2. After rebooting into the server kernel, I attempted to run drakconf with the idea of removing old kernels by hand, but I never got that far. After very briefly showing the window on the screen, a second or less, it crashed. When run from the terminal, I see this: # mcc Too late to run INIT block at /usr/lib/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 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal So far, I have only seen this on this system, just about 30 minutes ago. I have some 32-bit hardware that I can check later today to see if it does this, too. I have not seen it on any of my 64-bit systems - yet - but I haven't tried them all, either. Marking this as critical, as drakconf is completely unusable on this install.
Priority: Normal => High
I can't reproduce this on any of my other 32-bit installs, either on real 32-bit hardware, or on another 32-bit install on some other 64-bit hardware. So, this appears to be something unique to this one system. Reducing both priority and severity, since only my system is affected.
Severity: critical => normalPriority: High => Normal
Not sure what can be the root cause, all that messages are part of successful test https://bugs.mageia.org/show_bug.cgi?id=32202#c33 https://bugs.mageia.org/show_bug.cgi?id=32202#c34
CC: (none) => j.alberto.vc
Is it only drakconf that have the problem? - i.e drakrpm works? Does it help to downgrade webkit?
CC: (none) => fri
Yes, drakrpm still works. That makes me suspect a webkit2 relationship as well, but I haven't had a chance to try that yet. And the drakconf update was done to "fix" a somewhat similar issue involving webkit2, as well. Perhaps I should try downgrading drakconf first. It seems odd, though, that everything is OK with the 64-bit Plasma install on the same hardware.
Sorry Thomas, can't reproduce on my i586 full updated mcc Too late to run INIT block at /usr/lib/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 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223. "cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 841. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal But not crash , use a few tools without issues
Doing something wrong with the command - can't get drakconf or webkit to downgrade - too tired to figure it out tonight.
Using drakrpm to remove old kernels by hand, I found two mga8 server kernels still installed. That means this had to be an upgrade from mga8 to mga9. I don't remember now when that was, or how I upgraded. Could have been almost any time during testing, or when mga8 went EOL. I'm now thinking that maybe a fresh, clean install could cure the problem. I mean, there could have been an rpmnew that I ignored somewhere along the line that has now come back to bite me, for example. Some test or another that I did that's left something behind. Something like that. I know that upgrades, done correctly, are much more reliable than I thought years ago, but still, no matter how many we test they aren't perfect. Worth a shot, I think.
Nope. Didn't help. Fresh install from the netinstall iso, retaining /home, still showing the issue. Sigh.
Taking advantage of a rainy day, more testing on this. I installed from the 32-bit classic iso. After the first boot, drakconf was working. Then I went after the hundreds of updates - except for drakconf and webkit2. Drakconf still working after another reboot. So that narrows it down. Updated again, this time just drakconf and drakconf-icons. Rebooted. Drakconf still works. So then I downgraded drakconf (I had not used the full package name before), and then updated webkit2. Next reboot used the new webkit2 and old drakconf. Crash. So... Webkit2 is triggering a crash of drakconf, both new and old versions, on this hardware with 32-bit Xfce systems, but not with 64-bit Plasma systems. There are other open bugs about drakconf crashes on other hardware, so this could be yet another with the same base cause. I will let others decide if this bug should be a duplicate of one of those other bugs.
As root run strace drakconf And also after the crash run dmesg Let's see if we can squash this
Created attachment 14540 [details] strace results of failed mcc
Created attachment 14541 [details] dmesg from after the failure
Created attachment 14542 [details] Journal of a session where draconf crashed
Perhaps would be good other webkit2 update Quoting part of https://webkitgtk.org/2024/05/16/webkitgtk2.44.2-released.html "Fix several crashes and rendering issues"
It's clear in the dmesg in comment#12 that the fail is produced by webkit2 Assingn to all packagers an CC to Jani who made the current package
CC: (none) => jani.valimaaSource RPM: (none) => webkit2-2.44.1-1.mga9.src.rpmAssignee: bugsquad => pkg-bugs
webkit2.44.2 seem to be expected by security Bug 33232
Depends on: (none) => 33232
*** Bug 34305 has been marked as a duplicate of this bug. ***
CC: (none) => guillaume.royer
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=34305
I am closing this as old. If anyone still sees it, please reopen. We recently had an update of webkit2 to 2.44.4 in 2025-11-14, 2025-11-25 to 2.50 and currently a minor update of that is in testing.
Status: NEW => RESOLVEDResolution: (none) => OLD
It's still in effect on this one install. I just did a test of a cups update on this install, where there were no printers yet installed, and when I went to run MCC to install one, it crashed before the window was fully drawn. I did what I wanted to do using the command line. I'm not so sure bug 34305 is actually a duplicate of this bug. While there are some similarities in symptoms, there are also some differences. I'm removing it as a duplicate. This still only affects a 32-bit install on this 2010 64-bit hardware, probably a rare thing. And, the individual drak tools can still be run from the command line. Since there's been no movement on it, perhaps a resolution of "won'tfix" would be more appropriate.
Resolution: OLD => WONTFIX
No change after installing the latest webkit2 update candidate.
(In reply to Thomas Andrews from comment #9) > I installed from the 32-bit classic iso. After the first boot, drakconf was > working. Then I went after the hundreds of updates - except for drakconf and > webkit2. Drakconf still working after another reboot. So that narrows it > down. > Updated again, this time just drakconf and drakconf-icons. Rebooted. > Drakconf still works. So then I downgraded drakconf (I had not used the full > package name before), and then updated webkit2. Next reboot used the new > webkit2 and old drakconf. Crash. > So... Webkit2 is triggering a crash of drakconf, both new and old versions, > on this hardware with 32-bit Xfce systems, but not with 64-bit Plasma > systems. Retrospectively: that was a good thorough test, TJ.
Two things: - I thought of how to pin down the culprit updated package(s), but it would be incredibly painful & tedious to do (because they are numerous); and with M10 ISO testing in full swing, not now! - Webkit2 has just had another update (7/9 pkgs on my system), so worth re-trying the fault.
CC: (none) => lewyssmith
I already tried the updates, when they were in testing.That was where comment 20 came from. Since no one else seems to see this, my present working plan is to try an upgrade to Cauldron from the next round of isos. I'd try it now, but the first round test i686 CI iso has some issues. If the upgrade fails (quite possible with an alpha iso) I'll do a new install. The Live alpha1 iso doesn't show the issue in Live mode, so it could be the "fix" will be to upgrade to Mageia 10. Not the first time I've seen that.
Also valid in Mageia 10 Cauldron. I have heard of another user with the same issue. He is also dealing with an i586 install, and with integrated Intel graphics. A clue, perhaps? Re-opening, since I'm no longer the only one to see this. Also making it a Cauldron bug. Hmmm. I'm unsure how the "Hardware" field ought to be set, because the hardware is x86_64, but the only arch affected is i686/i586. Leaving as is. If it should be changed, please do.
Status: RESOLVED => REOPENEDHardware: i586 => i686Resolution: WONTFIX => (none)Flags: (none) => affects_mga9+Version: 9 => Cauldron
Still not affected, clean installation 10Beta1+updates How many memory have in affected system?
Maxed out at 8GB. Does your hardware use the i915 driver?
(In reply to Thomas Andrews from comment #26) > Maxed out at 8GB. Does your hardware use the i915 driver? The 810 and later
Are you using mirrorlist or custom mirror?
Specific mirror, always. Either math.princeton or distrib-coffee. If one isn't working for some reason, I switch to the other.
TJ, it is unclear whether this is an M9 or Cauldron/M10 problem...
Summary: drakconf crashes immediately after updating it, kernel, and webkit2 and rebooting => drakconf crashes immediately, after updating webkit2 and rebooting
On my problem machine, it is both. It was there when I had i586 Xfce M9 on that install, and still there after installing i686 Xfce Cauldron. I hadn't run it for a while, so I just checked it again, booting into Cauldron, getting updates, and rebooting. (new kernel) The issue is still there. MCC starts to show, and is up for maybe 2-3 seconds, but before it gets fully drawn it crashes. I get this if I try from the command line: $ mcc Too late to run INIT block at /usr/lib/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 539. Attempt to call undefined import method with arguments (":helpers" ...) via package "ugtk3" (Perhaps you forgot to load the package?) at /usr/lib/libDrakX/ugtk3.pm line 1501. "cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 841. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
Change something if set modesetting as graphic driver?
(In reply to katnatek from comment #32) > Change something if set modesetting as graphic driver? Need to reboot after made the change
(In reply to katnatek from comment #32) > Change something if set modesetting as graphic driver? Yes, it works OK after that, in Cauldron. I don't have a Mageia 9 i586 install on that laptop to test with that. It replaced my custom desktop wallpaper (photo I took of the St. Lawrence River) with the standard Mageia one, but that's a minor thing. MCC seems to work normally.
Then for both mga10 i686 issues with mcc in i686 Switch to modesetting as graphic driver is a workaround That is interesting
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=35053
CC: lewyssmith => (none)