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