Yelp 100% loads processor when reading gnumeric-help or About Ubuntu

[Ansus]

When opening help in Gnumeric, it starts to 100% load the processor. When closing the help window, the load ends.

[Pedro Villavicencio (pedro)]

Thanks for the report, Which version of Ubuntu and gnumeric are you running?

[Ansus (neptunia)]

Version 1.8.2

[Ansus (neptunia)]

Ubuntu 8.04

[nickhtp (nick1977)]

I think the reason for this could be due to one of three utilities:

1. procps or /proc, which the kernel gets/puts information entries from to the O.S. process table

2. libgnomevfs2-0 (>=1:2.17.90), I have had problems with this segment of gnome, specifically its handling of memory and backgrounding tasks associated with any and all declared memory with several programs. I use the words any and all for a valid reason. That reason is memory, performance and the way we all measure speed under linux need to be reinvented to reflect actual I/O use based on open and transparent CPU metrics, including volts and /not/ malloc.

3. libpopt0 is calling or referencing a function that isn't there and gets stuck cycling a bad case statement or for, while loop?

[bs66 (bugsquad66)]

i can confirm that with intrepid alpha 6 and gnumeric 1.8.3-3ubuntu2 the processor is at 100% for a very long time after loading the help file with "help/contents".

however, if you wait long enough it will go back to 0%.

my guess is that the help engine (yelp 2.24.0-0ubuntu1) does some work with the loaded help file in the background.

i get similar results when loading other help files in yelp.

i am unsure this is a bug. i change from "affects" gnumeric to yelp.

questions:

can you please confirm that the cpu returns to 0% if you wait for a long time?

also, do you know if the same problem exists in previous versions of xubuntu?

[bs66 (bugsquad66)]

i suggest that someone with enough rights changes "importance" to low.

[bs66 (bugsquad66)]

on a 3ghz computer it takes about one minute before the cpu returns to 0%, and as you use xubuntu you probably have a less powerful computer, so it will probably take several minutes on your system.

[nickhtp (nick1977)]

Is it scrollkeeper?

 -------------- Original message ----------------------
From: bs66 <email address hidden>
> i can confirm that with intrepid alpha 6 and gnumeric 1.8.3-3ubuntu2 the
> processor is at 100% for a very long time after loading the help file
> with "help/contents".
>
> however, if you wait long enough it will go back to 0%.
>
> my guess is that the help engine (yelp 2.24.0-0ubuntu1) does some work
> with the loaded help file in the background.
>
> i get similar results when loading other help files in yelp.
>
> i am unsure this is a bug. i change from "affects" gnumeric to yelp.
>
> questions:
>
> can you please confirm that the cpu returns to 0% if you wait for a long
> time?
>
> also, do you know if the same problem exists in previous versions of
> xubuntu?
>
> --
> Gnumeric help 100% loads processor
> https://bugs.launchpad.net/bugs/268845
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “gnumeric” source package in Ubuntu: New
> Status in “yelp” source package in Ubuntu: Confirmed
>
> Bug description:
> When opening help in Gnumeric, it starts to 100% load the processor. When
> closing the help window, the load ends.

[nickhtp (nick1977)]

I dissent.

Explaining away this problem by comparing performance to a high-end machine does not necessarily move the bug's status to invalid. As both a documentor and developer I want to know *why* this bug is occurring.

I move that this bug's status be returned to what it was before "invalid". Anyone second that motion?

-Nicholas
 -------------- Original message ----------------------
From: bs66 <email address hidden>
> ** Changed in: gnumeric (Ubuntu)
> Status: New => Invalid

 -------------- Last Original message ----------------------
> > on a 3ghz computer it takes about one minute before the cpu returns to
> > 0%, and as you use xubuntu you probably have a less powerful computer,

[bs66 (bugsquad66)]

winlundn, i just recently started learning about how to triage bugs, and i have much to learn. i think the bug is in yelp, and not at all related to gnumeric. the process that eats cpu cycles is yelp. please feel free to change this report in any way you like. i would love to learn more from experienced bugsquaders.

[Ansus (neptunia)]

Still the same in Intrepid.

[Pedro Villavicencio (pedro)]

is this still an issue? could somebody get a backtrace of yelp ?

[Goyo (goyodiaz)]

In Xubuntu 9.04, Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz, opening gnumeric help raises CPU load to > 95% for one minute or so.

[Rami Al-Rfou' (rmyeid)]

Architecture: i386
DistroRelease: Ubuntu 9.10
Package: yelp 2.27.4-0ubuntu1
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-7.27-generic
Uname: Linux 2.6.31-7-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Rami Al-Rfou' (rmyeid)]

The same happen when you try to open About Ubuntu, I attached a screenshot to confirm that.

[Pedro Villavicencio (pedro)]

that needs to be send upstream by someone having the issue at bugzilla.gnome.org

[luojie-dune (luojie-dune)]

Same problem here, happened version 1.9.14-17, 1.8.4 and yelp must cause the problem.

Many users in Chinese Ubuntu Forum confirmd high CPU usage and slow startup problem around yelp.

 English limited the bug report/ *#*

[spenner (stephenpenner)]

I can confirm that _all_4_ 64-bit CPU cores are occupied at 100% indefinitely (ie more than 15 minutes already) by yelp under these conditions:

Ubuntu 9.04
kernel 2.6.28-17
RAM: 12 GB
Processor: i7-920 (4 hyperthreaded Intel cores running at about 2.4 GHz each)
HD: WD 1-TB
Clicking on "System->About Ubuntu" kicks off the problem, which shows no sign of ending yet. Ubuntu becomes utterly unresponsive.

This seems like a pretty serious problem, given that yelp starts up at what I would consider to be rather unexpected times. It also appears to be problematic across multiple versions of Ubuntu. Is there any way to remove yelp completely from the picture, at least until it behaves sociopathically?

[spenner (stephenpenner)]

One more tidbit: yelp not only completely monopolizes all of the CPU cores (25 minutes and counting), but it also takes ever-increasing amounts of RAM: 9 GB and counting.

Even the mouse is almost completely unresponsive. Seems like the current Ubuntu versions of yelp make fairly effective assault tools...

[Charlie Kravetz (cjkgeek)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace of yelp following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

[spenner (stephenpenner)]

Unable to use gdb to capture any info: gdb becomes completely unresponsive once I have started the yelp process(es) (ie cannot issue commands like "backtrace full", or anything else). However, before gdb goes away permanently, I see this:

"
spenner@bigneo:~$ gdb yelp 2>&1 | tee ~/gdb-yelp.txt
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) handle SIG33 pass nostop noprint
Signal Stop Print Pass to program Description
SIG33 No No Yes Real-time event 33
(gdb) set pagination 0
(gdb) run ghelp:about-ubuntu
Starting program: /usr/bin/yelp ghelp:about-ubuntu
[Thread debugging using libthread_db enabled]
[New Thread 0x7f819cfb57e0 (LWP 5123)]
[New Thread 0x7f818be65950 (LWP 5126)]
[New Thread 0x7f818b664950 (LWP 5127)]
[New Thread 0x7f818ae63950 (LWP 5128)]
[New Thread 0x7f818a4df950 (LWP 5129)]

(yelp:5123): Yelp-WARNING **: Yelper initialization failed for 0x2ecdc20

OMF category 'Applications|Other' not recognised, ignoring.
[New Thread 0x7f8187a5c950 (LWP 5130)]
[New Thread 0x7f8186f8a950 (LWP 5131)]
[New Thread 0x7f8186726950 (LWP 5132)]
[Thread 0x7f8186f8a950 (LWP 5131) exited]
[New Thread 0x7f8186f8a950 (LWP 5133)]
[Thread 0x7f8186726950 (LWP 5132) exited]
[New Thread 0x7f8186726950 (LWP 5134)]
[Thread 0x7f8186f8a950 (LWP 5133) exited]
[Thread 0x7f8186726950 (LWP 5134) exited]
"

Also, it looks like even after I have logged on to the unresponsive computer from a Windows 2000 computer (via putty), and killed the gdb and yelp processes, the instance of Firefox 3.0.17 that was open when I started the debug run of yelp now fails to respond at all. Also, the CPU usage remains way too high (about 65% in Xorg, compared to less than 1% before the yelp run) and the memory usage stays too high as well (about 2.5 GB, compared to about 0.8 GB before the yelp run).

Once I have killed the gdb and yelp processes via the putty link, the following line appears immediately below the last quoted line above:

"
Terminated
spenner@bigneo:~$
"
Note that the theft of the CPU cycles and memory appears to be associated with running yelp with a nontrivial parameter (ie "ghelp:about-ubuntu"). When I run yelp by itself (ie no parameters), I get the error message reported in Bug #425709:

"
chris@chris-desktop:~$ yelp

(yelp:10789): Yelp-WARNING **: Yelper initialization failed for 0x95d0e20

OMF category 'Applications|Other' not recognised, ignoring.

A dialogue box appears after around 20 seconds:

Unable to load page

 The requested URI "file:///fakefile#index" is invalid

[OK]
"
One other thing to note: The whole reason I even clicked "About Ubuntu" in the first place was that I was trying to upgrade my installation of Firefox 3.0.17 to something a little more recent (3.5, 3.6, 3.7). However, none of the packages I downloaded from "PPA for Ubuntu Mozilla Daily Build Team", and tried to install actually installed. When I couldn...

[Charlie Kravetz (cjkgeek)]

Thank you very much for the effort to get a backtrace on this issue. I have forwarded the information to the developers of yelp. You can track it and make comments at: https://bugzilla.gnome.org/show_bug.cgi?id=557456 . If you prefer, you may continue to make comments here.

[nicolagiacobbe (giacobbe-nicola)]

Confirm the bug on Ubuntu 10.04 with Yelp 2.30.0 using Gnumeric 1.10.1-1ubuntu1.
On a T6500 double core with 4GByte RAM it takes from 30 to 60 seconds to open an help page, with processor load around 66% for first processor and 33% for the second one. Once this time has elapsed help is much more responsive.
Closing Gnumeric and opening help after restarting it does not cure the problem but the second time the system seems more responsive (about 15% quicker, I guess).

[nomnex (nomnex)]

I have the same issue on Fedora 13 LXDE Spin. Yelp eats up 100% cpu when browsing the gnumeric user manual.

[Matthew East (mdke)]

Please advise whether this problem still exists in Natty with yelp 3.0. A lot of work has gone into a redesign of yelp for this release and most speed issues seem to be resolved.

[Charlie Kravetz (cjkgeek)]

I attempted to reproduce this issue using Xubuntu 11.04 up-to-date as of 2011-05-02. Gnumeric no longer uses Yelp to display help, therefore, this can not be reproduced in Natty. Since the bug was reported to happen in two releases that are now EOL, I am marking the Ubuntu Yelp task invalid.

[Goyo (goyodiaz)]

Gnumeric does use yelp to display help using Ubuntu 11.04 Natty and Unity, but it's a different yelp which is not affected by this bug --at least for me.

[Ravi Kumar (kumarravi-kumar267)]

I have the same problem. Help!

Release : Ubuntu 11.04 (natty)
GNOME : 2.32.1
Kernal : 2.6.38-8-generic

I attached a screenshot for confirming this.

[chacka (koerdt)]

also on precise:

Ubuntu precise (development branch)
3.2.0-23-generic
yelp 3.4.0-0ubuntu1

may lead to overheating

[Martin Spacek (mspacek)]

I noticed this as well, after installing GNU PSPP, clicking Help>Reference Manual, and then quitting. "yelp info:pspp" showed 100% in gnome-system-monitor. After killing yelp, then repeating what I did above in GNU PSPP, yelp showed up again, but wasn't using any CPU, and exited after I quite PSPP. This is on natty (Ubuntu 11.04) on a Core2 Quad core.

2.6.38-16-generic
yelp 3.0.0-0ubuntu2

[Michael Uphoff (michael-uphoff)]

This bug stille hides in xubuntu 14.10, yelp version 3.12.0