GNOME Bugzilla – Bug 744636
help (yelp) eats 100% cpu
Last modified: 2016-09-05 10:49:51 UTC
Recipe: Start fresh copy of gnumeric. Click on the search box, key in something, e.g. "data" <enter> Click on one of the results, e.g. "Data in Gnumeric" Use top(1) or whatever to observe that yelp goes to 100% and stays there. This is 100% reproducible chez moi. Many of the details above can be varied, leading to the same result. Closing the help window makes the problem go away. gnumeric --version gnumeric version '1.12.21' datadir := '/usr/share/gnumeric/1.12.21' libdir := '/usr/lib/gnumeric/1.12.21' uname -a Linux asclepias 3.18.0+ #2 SMP Sun Dec 21 18:25:03 MST 2014 x86_64 x86_64 x86_64 GNU/Linux
Which search box? You seem to be missing something in your recipe.
The box at the top of the help popup. The place where you type stuff that you want to search for. The field that starts out with a square symbol on the left, but changes it to a magnifying-glass search symbol when you click on it. Suggestion: Do the experiment. Hit F1 and see what you get. There aren't a lot of possibilities.
Hitting F1 means you are in yelp. Please file the bug report against yelp.
Andreas: Yelp IS part of GNOME.
How is this some "online" help (as this is written in the bug summary? Which distribution is this about? Which Yelp version is this about? Does this also happen when opening other application help files via Yelp?
yelp --version yelp 3.12.0 That's what's bundled with the current Ubuntu (utopic). uname -a Linux asclepias 3.18.0+ #2 SMP Sun Dec 21 18:25:03 MST 2014 x86_64 x86_64 x86_64 GNU/Linux Yes, running yelp ghelp:gnumeric from the command line produces the exact same scenario, 100% CPU usage. Running the actual gnumeric program is not necessary.
(In reply to John Denker from comment #6) > Yes, running > yelp ghelp:gnumeric > from the command line produces the exact same scenario, Does the problem also happen with other help files than gnumeric? Was this reported to Ubuntu's bug tracker to make sure that this is actually an issue in upstream code? https://patches.ubuntu.com/y/yelp/yelp_3.12.0-1ubuntu2.patch isn't extremely small...
1) Sorry about "online" in the Subject: line. I guess I meant /interactive/ or something like that 2) Yes, it bugs in the same way with other help files: yelp with no arguments opens "Ubuntu Desktop Guide". Then search for "data" (or "window"). Click on "What to back up" (or "Keyboard navigation"). CPU usage goes right to 100% and stays there. FWIW this is not associated with any great amount of disk activity. ------- New info: The command valgrind yelp goes right to 100% and stays there. It hangs after putting the title ("Gnome Desktop Guide") in the headline box, but before rendering anything in the rest of the window. I know valgrind is slow, but I waited a couple of minutes. It's not that slow. This even-worse symptom seems to be 100% reproducible under valgrind. Changing the malloc-fill does not seem to have much effect. The fact that the symptom is not quite the same is confusing.
Was this reported to Ubuntu's bug tracker to make sure that this is actually an issue in upstream code? https://patches.ubuntu.com/y/yelp/yelp_3.12.0-1ubuntu2.patch isn't extremely small...
I do noticed an excessive CPU usage too, even after closing yelp. In Fedora 22. Opening Calculator Help, searching for "Pi", clicking link "Variables" and scrolling a little. Then, even after closing the window CPU usage stays at 12% which is quite a lot on an i7 with 8 cores, for doing nothing (ie. one CPU is on 100% all the time).
Created attachment 304575 [details] gdb: `t a a bt full` of yelp running in a busy loop after closing I am seeing the same behavior in yelp 3.16.1 on Fedora 22. These are the steps to reproduce: 1. start yelp (no matter how) 2. click the global search button (in header bar), don't use Ctrl+F (page search) 3. search for anything which cannot be found (e.g. "bla", the German word for "foo") 4. close yelp 5. observe with your favorite system monitor What happens: yelp runs with 100% CPU on one core. Backtrace attached. Note that yelp still reacts to SIGTERM, but I don't think it exits cleanly.
I see the same behavior in yelp 3.16.1 in Arch Linux, opening yelp, making *any* query in the header bar and closing yelp causes cpu usage to go 100%
Why is this bug still marked as NEEDINFO? What information is needed?
*** Bug 770857 has been marked as a duplicate of this bug. ***
I only see one generic Yelp call in the provided stack trace (hence I can imagine it's related to underlying libraries), and the versions mentioned in this ticket are 3.10 and 3.16. Can anyone reproduce this problem in Yelp 3.22 or 3.20?
I think this bug report is a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=661509. Anyway, it is gone in 3.20. See also this downstream report: https://bugzilla.redhat.com/show_bug.cgi?id=1287818
Yes, 3.20 seems to have fixed this issue. I don't see zombie process anymore. (using 3.20.1-1ubuntu2)
*** This bug has been marked as a duplicate of bug 661509 ***