Description of problem: Poking around in drakhardware, it sometimes hang, using one core fully. No other part of MCC i tried shows this problem, and no other app (tried very little on this specific fresh Live) but I can use the system, i.e browse internet and write this. Version-Release number of selected component (if applicable): drakxtools-18.72-1.mga10 On USB Live alpha1 i686 xfce with persistence created yesterday, full updates as of today, for example it is running kernel 6.18.7-1 How reproducible: Sometimes, on both machines using same USB system: Asus D260 and Thinkpad T510 First time i tried drakhardware on any mga10 so can not say much more. Steps to Reproduce: Open every hardware class dropdown in left pane. Sometimes it hang on one or another, but maybe not next time, or another item then If still not hung: scroll, resize window, move window I see no suspect messages neither in terminal launching drakhardware, or in system journal.
M10 Beta is out; I think just be keeping up-to-date (Cauldron repos) you should be equivalent. Does this still happen? Is this both x64 & x32?
CC: (none) => lewyssmith
My HP Zbook 15 G4 has this issue, but occours 100% of the time. Using the MCC > Hardware (or cli drakhardware) will result in a loop/hang after a minute or 2. Running with debug at command line gave this report drakhardware --debug 2>&1 | tee drakhardware-debug.log 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. Ignore the following Glib::Object::Introspection & Gtk3 warnings Argument "bold" isn't numeric in subroutine entry at /usr/share/perl5/vendor_perl/Gtk3.pm line 1680. That made my AI helper try to pin down the cause, and suggested running with no GTK elements (drakhardware --no-gtk) There was no change to the hang and the --no-gtk switch seemed to do nothing, still ran full GUI. The next suggestions was to make edits to ugtk3.pm Nothing made meaningful change but pointed to the helper elements being a bit confused between ugtk3.pm and drakhardware python bits..? Here is a few things tried and errors seen :- ------ AI influnced poking about at this bug ------ --------------- Drakhardware Testing ---- drakhardware --debug 2>&1 | tee drakhardware-debug.log 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. Ignore the following Glib::Object::Introspection & Gtk3 warnings Argument "bold" isn't numeric in subroutine entry at /usr/share/perl5/vendor_perl/Gtk3.pm line 1680. Warning: skip "is_pciexpress" field => "1" Warning: skip "sysfs_device" field => "/sys/bus/pci/devices/0000:00:02.0" Warning: skip "nice_bus" field => "PCI Express" Warning: skip "Handlers" field => "HASH(0x55fe9822acc0)" modinfo: ERROR: Module Card:Intel Kernel Mode setting (Xorg modesetting) not found. ----- ugtk3.pm edits 1. +use Exporter (); Why: ugtk3 was using export tags and lists without actually loading Exporter. Effect: makes the export/tag system behave properly; doesn’t touch the hang. 2. @EXPORT / @EXPORT_OK for add_icon_path + our @EXPORT = ('add_icon_path') + push @EXPORT_OK, 'add_icon_path'; Why: to give add_icon_path a clean export path once :helpers was no longer used. Effect: makes it importable if anyone relies on exports; you later bypassed this by calling ugtk3::add_icon_path directly. 3. Stubs for bold, italic, add_icon_path + sub bold { $_[0] } + sub italic { $_[0] } + sub add_icon_path { return; } Why: specifically because of the Argument "bold" isn't numeric warning and the broken helper semantics under Gtk3. Effect: turns those helpers into harmless no‑ops: bold/italic just return the text unchanged. add_icon_path does nothing. Goal: silence the warnings and keep the old call sites from blowing up—not to change control flow. 4. Try diffrent self‑imports + use ugtk3 qw(:helpers :wrappers); - use ugtk3; ------ Summary of fooling about ------ The hang: Present from the beginning. Unchanged by any of these edits. Likely in drakhardware/interactive’s event/idle loop with Gtk3/GLib. The ugtk3/drakhardware edits: Were about: removing the broken :helpers import, silencing the "bold"/Gtk3 warnings, making helper calls safe no‑ops, and avoiding self‑import weirdness. They cleaned up the error surface, but did not fix or cause the hang
CC: (none) => greg
CC: (none) => westel
(In reply to Lewis Smith from comment #1) > M10 Beta is out; ... > Does this still happen? > > Is this both x64 & x32? Yes; Marc report on QA list this happens on beta1 x86_64 Xfve Live, Benedict on CI x86_64
Assignee: bugsquad => mageiatools
(In reply to Morgan Leijström from comment #3) > (In reply to Lewis Smith from comment #1) > Yes; Marc report on QA list this happens on beta1 x86_64 Xfve Live, Benedict > on CI x86_64 should be CI i686 ;)
During testing MGA10-beta1 on Live Xfce 64_86, on MGA10-beta1 Live Plasma 64 bit, and on Live Gnome 64_86, I reported in QA-discuss@ml.mageia.org that I see the following issue: After opening MCC-> Detect Hardware, the list of detected h/w om my Intel NUC pc shows up fast. But after about 10 seconds the list freezes. This is repeatable on both Xfce, Plasma and Gnome. At first I can click on several lines of h/w, and the screen shows the properties of each hardware. With or without clicking in the list, the list freezes after about ten seconds. MCC stays alive. After closing and reopening Detect Hardware the same issue occurs. This happens 100 percent of the time in both Plasma, Xfce 64_86 and Gnome. It is the same issue as under MGA10-alpha1, and MGA10 alpha1 Round 2. All the tested systems were booting from a usbu stick with persistence. I didn't install the systems on my pc. Updating the distros on the persistence usb stick, and rebooting, didn't make any difference for this freezing during Detect Hardware. Marc.
CC: (none) => laan.marc
I get it too. When I launch sudo strace drakhardware I get, when the application become unresponsive, a flow of: wait4(-1, 0x7fff2a26aa94, WNOHANG, NULL) = -1 ECHILD (Aucun processus enfant) When I launch it in debug mode, enabling trace, I get a lot of this line 476: do { $child_pid = waitpid(-1, POSIX::WNOHANG); undef $pid if $pid == $child_pid } until $child_pid > 0; This is coherent in both approaches, with waiting pid of type WNOHANG The culprit is here: https://gitweb.mageia.org/software/drakx/tree/perl-install/standalone/harddrake2#n476 However, I can't understand about where is the problem.
CC: (none) => yves.brungard
"Aucun processus enfant" means "No child process". I have questionned Claude.ia, here the answer: "When `waitpid` returns `-1` (which corresponds to `ECHILD` - no child process), here's what happens in the loop: 1. `$child_pid = waitpid(-1, POSIX::WNOHANG)` assigns `-1` to `$child_pid` 2. The condition `undef $pid if $pid == $child_pid` is evaluated, but it probably does nothing (unless `$pid` was already `-1`) 3. The condition `until $child_pid > 0` is tested: `-1 > 0` is **false** 4. So the loop **continues** and calls `waitpid` again and again... **This is an infinite loop!** The function gets stuck calling `waitpid` indefinitely, which always returns `-1`, because the exit condition `until $child_pid > 0` is never satisfied. This is indeed a bug in the code. The condition should instead be: > until $child_pid <= 0; # stop when there are no more children to reap Or even better: > while ($child_pid > 0); # continue as long as we're reaping children With the current code, if the signal handler is called when there are no (or no more) child processes to reap, the program enters an infinite loop that wastes CPU unnecessarily." Even if this is true, why the problem appears only now? The code is unchanged since 2016.
(In reply to papoteur from comment #7) > until $child_pid <= 0; # stop when there are no more children to reap This change seems to allow the application remains responsive. I don't see if there is side effects.
(In reply to papoteur from comment #8) > (In reply to papoteur from comment #7) > > until $child_pid <= 0; # stop when there are no more children to reap > > This change seems to allow the application remains responsive. > I don't see if there is side effects. That change stopped to endless loop in my installation.. Now the drakhardware no longer hangs at near 100% CPU. And now remains responsive Thanks.
Congratulations papoteur on resolving this. (In reply to papoteur from comment #7) > This is indeed a bug in the code. The condition should instead be: > > until $child_pid <= 0; # stop when there are no more children to reap > Or even better: > > while ($child_pid > 0); # continue as long as we're reaping children (In reply to papoteur from comment #8) > > until $child_pid <= 0; # stop when there are no more children to reap > This change seems to allow the application remains responsive. > I don't see if there is side effects. Did you try the "even better" 'while' alternative? (In reply to Greg Mathe from comment #9) > > > until $child_pid <= 0; # stop when there are no more children to reap > That change stopped to endless loop in my installation.. > Now the drakhardware no longer hangs at near 100% CPU. And now remains > responsive BTAIM, this change resolves the problem. If it is already in Cauldron, can this be closed Fixed? Or pushed & closed.
(In reply to Lewis Smith from comment #10) > If it is already in Cauldron, can > this be closed Fixed? Or pushed & closed. It is not yet in cauldron nor on git.
commit 1d135cfa975bc8f3478f226931e772f74e0abd4c Author: Papoteur <papoteur@...> Date: Mon Feb 2 13:58:22 2026 +0100 Avoid an infinite loop (mga#35061) When `waitpid` returns `-1` (which corresponds to `ECHILD` - no child process), here's what happens in the loop: 1. `$child_pid = waitpid(-1, POSIX::WNOHANG)` assigns `-1` to `$child_pid` 2. The condition `undef $pid if $pid == $child_pid` is evaluated, but it probably does nothing (unless `$pid` was already `-1`) 3. The condition `until $child_pid > 0` is tested: `-1 > 0` is **false** **This is an infinite loop!** until $child_pid <= 0; # stop when there are no more children to reap --- Commit Link: https://gitweb.mageia.org/software/drakx/commit/?id=1d135cfa975bc8f3478f226931e772f74e0abd4c
Yves, please close this'fixed' when you are happy with it, and it is in Cauldron.
CC: lewyssmith => (none)
Now in cauldron, since drakx 18.74. We consider that it is fixed. Please reopen if this is not the case.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED