Bug 33208

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 => normal
Priority: 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

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.valimaa
Source RPM: (none) => webkit2-2.44.1-1.mga9.src.rpm
Assignee: bugsquad => pkg-bugs

webkit2.44.2 seem to be expected by security Bug 33232