yelp steals focus, cannot be killed, hogs system

Bug #1005510 reported by Guy Verrijdt on 2012-05-28
This bug affects 2 people
Affects Status Importance Assigned to Milestone
yelp (Ubuntu)

Bug Description

When opened from certain applications (eg grsync and terminal) but not others (eg nautilus and gedit), the yelp window stays empty, steals focus (forces itself on forground) and cannot be force killed.
The system becomes unusable, although everything seems to continue working.
CPU load increases dramatically, Xorg is the main culprit
Only solution to get control back over the system is a Alt-SysRq-REISUB reboot.
Nothing relevant in .xsession-errors; i have no idea where to look or what to look for in other logs
Should i file a bug? Yelp? Xorg?
Anyone else with this problem?
Please help...
Here's a video showing what the problem is:

I'll be happy to provide log entries, upon request.
I can't gdb backtrace since yelp started from terminal without arguments works flawlessly.

Ubuntu 12.04 64-bit
3.2.0-25-generic Kernel
Gnome 3.4.1
5.8 Gb RAM Intel® Core™ i5-2430M CPU @ 2.40GHz × 4
AMD Radeon HD 7400M Series

Jeremy Bicha (jbicha) wrote :

Thank you for taking the time to report this bug and help make Ubuntu better.

I've never seen this problem and I have a less powerful computer than you do.

What happens if you run yelp ghelp:gnome-terminal ?
Does this problem still happen if you use the default Ambiance theme?

Guy Verrijdt (gverrijdt) wrote :

Thx for your quick answer and your efforts to help with this.

interestingly, this is what happens when i run yelp ghelp:gnome-terminal:

So no luck...

The video doesn't show, but the same behaviour is there using ambiance Gtk and window theme

I don't think it has anything to do with the power of my pc... other than this glitch it's running relatively smoothly

What else can i do to solve this?

Shaun McCance (shaunm-gnome) wrote :

Almost certainly the old forkbomb bug:

There are two things different between nautilus & gedit versus grsync & gnome-terminal:

1) The former use the help: scheme, the latter ghelp:
2) The former use Mallard, the latter DocBook

Something is causing Yelp not to recognize these documents, which makes Yelp tell the system to open them, which in turn tells Yelp to open them, ad infinitum.

Guy Verrijdt (gverrijdt) wrote :

Thank you for your information.

Maybe this gets me somewhere.
Tried installing 'docbook (which wasn't installed on my system)', no avail
Mallard seems not to be a package that can be (re)installed
Already tried reinstalling yelp earlier, also no avail

It confuses me that the command 'yelp ghelp:gnome-terminal' from cli doesn't trigger the bug, so the problem is in the 'link' between the app and yelp(?) Xorg CPU shoots up, maybe it's a Xorg thing? Compiz?

Am I the only one having this?

Thanks for further help...

Guy Verrijdt (gverrijdt) wrote :

From the link provided by Shaun, i see that this is known for a long time.

Nobody has solved it yet, but there is a way to get your system back without having to reboot: write script 'killall yelp' (killall gnome-help as suggested in the links doesn't work for me), create a launcher and add the icon to the unity launcher. Clicking this kills the yelp window (i wonder why Force Quit doesn't(?)).
I'm happy now i don't have to 'reisub' all the time anymore...

Nobody seems to be doing anything about it... why?
In my eyes, this is not a small problem. Doesn't anybody use the 'help' function?
For me this issue is solved, I know what to do next time, but i can image things like this drive people away from ubuntu/linux

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in yelp (Ubuntu):
status: New → Confirmed
patrick samples (ptrakk) wrote :

happens to me on debian wheezy

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.