Bug 442173 - YaST GUI hangs up in busy loop when it must display long lists
Summary: YaST GUI hangs up in busy loop when it must display long lists
Status: RESOLVED WONTFIX
: 406853 457035 481299 (view as bug list)
Alias: None
Product: openSUSE 11.0
Classification: openSUSE
Component: YaST2 (show other bugs)
Version: Final
Hardware: All openSUSE 11.0
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: Jiri Srain
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-06 08:45 UTC by Johannes Meixner
Modified: 2009-04-16 08:15 UTC (History)
6 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Meixner 2008-11-06 08:45:12 UTC
The YaST GUI needs too much time to display long lists.
In this case there is a "y2base" process running
at about 100% CPU like this ("top" output)
-----------------------------------------------------------
PID   USER  ... %CPU %MEM  TIME+  COMMAND                   
18196 root  ...  100 15.3 5:08.01 y2base                     
-----------------------------------------------------------
and nothing happens on the dialog so that for the user
it looks as if YaST has hang up.
By default (i.e.when YaST doesn't run in debugging mode)
there is nothing in y2log which indicates where it hangs.

To reproduce:
Run "yast2 scanner" as root and click the [Add] button
(you don't need a scanner to do this).
The [Add] button shows all available models
(several hundred up to about two thousand).
On my 3 GHz workstaion it needs more than 10 minutes
until the list of all available models shows up.

Juergen Weigert reported the issue to me and
some customers reported the issue too, see
https://bugzilla.novell.com/show_bug.cgi?id=406853#c0
https://bugzilla.novell.com/show_bug.cgi?id=406853#c14
https://bugzilla.novell.com/show_bug.cgi?id=434540#c9
Comment 2 Johannes Meixner 2008-11-06 08:49:53 UTC
*** Bug 406853 has been marked as a duplicate of this bug. ***
Comment 3 Johannes Meixner 2008-11-06 08:57:13 UTC
By the way:
I didn't detect the issue with my scanners because
my scanners are well autodetected and in this case
the [Edit] button is usually used to set it up.
Then only those models are shown in the list which match
to the manufacturer name of the autodetced scanner.
This results a much shorter list which shows up
after some seconds which looked o.k. for me.
But [Add] results the long delay in any case.
Comment 4 Johannes Meixner 2008-11-06 09:13:37 UTC
Another bad side-effect is that clicking the [Abort] button
has not the expected effect.
One can click [Abort] but then one must wait all the time
until the GUI has completed its job (i.e. until the list
finally shows up) and afterwards the module is aborted
just when the reason for the abort request is no longer valid.
Comment 5 Carlos Tonussi 2008-11-06 19:16:58 UTC
I went to try the line command yast2 scanner, but I did forget the 2 of yast2, so yast in test mode was started. For my surprise, there was no delay to configure my scanner. After chose edit option, the list of scanner models appeared immediately. I only spent the time needed to roll down such list without the aid of a mouse, and conclude the operation.

Ok...I did not pay attention to the comments above...everybody already knows the problem is in Yast GUI...
Comment 6 Stefan Hundhammer 2008-11-13 18:06:00 UTC
What widget are we talking about? Do you have a screen shot? Did you attach gdb to the process to see where it hangs?
Comment 7 Johannes Meixner 2008-11-14 08:23:43 UTC
To reproduce:
Run "yast2 scanner" as root and click the [Add] button
(you don't need a scanner to do this).
The [Add] button shows all available models
(several hundred up to about two thousand).
Comment 8 Johannes Meixner 2008-11-14 08:29:06 UTC
To help you to find out where it hangs:
You can run YaST in debugging mode.
Then y2log fills up with zillions of
messages what the GUI is doing
(remember it runs at about 100% CPU)
while it looks for the user as if it hangs.
Comment 10 Stefan Hundhammer 2008-11-14 11:12:18 UTC
If it's a selection box in 11.0, then there is nothing we can do about it. This is fixed for 11.1, but I don't see a reasonable way to back-port this for 11.0. There were just too many changes everywhere for a back-port.

So, this is FIXED for 11.1.
For 11.0, this is WONTFIX; you simply have to wait for the list to be completely built.
Comment 11 Elmar Stellnberger 2008-12-04 17:42:34 UTC
It always crashes on "store queue" after printer setup.
Comment 12 Elmar Stellnberger 2008-12-04 17:43:18 UTC
oops wrongly placed comment (does not belong to here).
Comment 13 Johannes Meixner 2009-01-07 08:21:47 UTC
*** Bug 457035 has been marked as a duplicate of this bug. ***
Comment 14 Johannes Meixner 2009-02-18 14:27:04 UTC
*** Bug 475989 has been marked as a duplicate of this bug. ***
Comment 15 Johannes Meixner 2009-03-25 08:25:09 UTC
See
https://bugzilla.novell.com/show_bug.cgi?id=481299#c10
"Gnome on Version 11.0 Yast runs light lightening"
for a workaround how to run it even in graphical mode:

Run the YaST scanner module in a Gnome environment
(more precisely use the GTK graphical user interface)
by calling it as root from the command line via

root@host# yast2 --gtk scanner

This should be the default when you have openSUSE 11.0 installed
with the Gnome desktop environment.

But when you have openSUSE 11.0 installed with the KDE desktop
environment, you need a lot of additional packages so that
it works to run a YaST module with the GTK GUI, see bug #388586

The easiest way is to "simply install the whole Gnome pattern"
via YaST because on nowadays multi-gigabyte harddisks it should
not really matter if there are several megabytes wasted
by installed software which is not actually needed.
Comment 16 Hubert Mantel 2009-03-25 10:42:24 UTC
So this seems to be exactly the same issue as #481299. IMHO this one should be closed as duplicate then. Johannes, do you agree?
Comment 17 Johannes Meixner 2009-03-25 13:46:32 UTC
From my point of view, bug #481299 is a duplicate of this bug here.
Comment 19 Thomas Göttlicher 2009-04-16 08:15:55 UTC
*** Bug 481299 has been marked as a duplicate of this bug. ***