After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 661509 - 100% CPU usage in Yelp
100% CPU usage in Yelp
Status: RESOLVED OBSOLETE
Product: yelp
Classification: Applications
Component: Mallard
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: Yelp maintainers
Yelp maintainers
: 744636 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-12 00:22 UTC by Robert Roth
Modified: 2016-09-05 10:49 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Valgrind (82.51 KB, text/plain)
2011-10-12 04:36 UTC, Fabio Durán Verdugo 		Details

Description Robert Roth 2011-10-12 00:22:12 UTC 
Forwarding from downstream Ubuntu - https://bugs.launchpad.net/ubuntu/+source/yelp/+bug/872114

Steps to reproduce:
1. Open Gnome Terminal
2. Press F1 to open the Gnome Terminal Help
3. Search for something using the search bar
4. Click the link on the top to go back to GNOME Terminal Manual

Expected result:
Yelp goes back to the GNOME Terminal Manual main page
What happens:
Yelp goes back, but the CPU usage of the Yelp process increases to 100% and stays at 100% until it's closed or killed.

Reproduced with Yelp 3.0.x and 3.2.0.
Comment 1 Fabio Durán Verdugo 2011-10-12 04:20:24 UTC 
$ gdb yelp
(gdb) set args  ghelp:///usr/share/gnome/help/gnome-terminal/C/gnome-terminal.xml
(gdb) run
when yelp get the 100% cpu press control +c to cancel the process and type

(gdb) thread apply all bt

+ Trace 228757

Thread 1 (Thread 0xb7188890 (LWP 16218))

  • #0 _int_free
    at malloc.c line 4898
  • #1 __GI___libc_free
    at malloc.c line 3738
  • #2 standard_free
    at /build/buildd/glib2.0-2.30.0/./glib/gmem.c line 101
  • #3 g_free
    at /build/buildd/glib2.0-2.30.0/./glib/gmem.c line 263
  • #4 g_source_unref_internal
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c line 1702
  • #5 g_main_dispatch
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c line 2470
  • #6 g_main_context_dispatch
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c line 3011
  • #7 g_main_context_iterate
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c line 3089
  • #8 g_main_loop_run
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c line 3297
  • #9 gtk_main
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkmain.c line 1367
  • #10 gtk_application_run_mainloop
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkapplication.c line 115
  • #11 g_application_run
    at /build/buildd/glib2.0-2.30.0/./gio/gapplication.c line 1323
  • #12 main
    at yelp.c line 50 


we get other debug?
Comment 2 Fabio Durán Verdugo 2011-10-12 04:36:11 UTC 
Created attachment 198834 [details]
Valgrind

Here valgind log 

$ G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log yelp  ghelp:///usr/share/gnome/help/gnome-terminal/C/gnome-terminal.xml
Comment 3 Dominique Leuenberger 2012-07-23 19:36:01 UTC 
This can still be reproduced on yelp 3.4.2
Comment 4 Matthias Clasen 2012-07-24 13:39:45 UTC 
libyelp/yelp-document.c:request_try_free looks fishy
Comment 5 Alexánder Alzate 2013-04-20 23:23:40 UTC 
I reproduced it on yelp 3.6.2-1

uname -a
Linux arch-linux-desk 3.8.7-1-ARCH #1 SMP PREEMPT Sat Apr 13 09:01:47 CEST 2013 x86_64 GNU/Linux
Comment 6 Adam Dingle 2013-05-16 11:33:02 UTC 
I see this too in yelp built from git master (current version = 3.8.1).  This also occurs when you open any search result page.
Comment 7 Juan A. Suarez Romero 2013-12-05 19:39:14 UTC 
Is this a duplicate of bug #557456 ?
Comment 8 Adam Dingle 2013-12-06 10:18:51 UTC 
I believe it is a duplicate, though I think this bug has a clearer description including a precise set of instructions for reproducing the problem.  I recommend marking that other bug as a duplicate of this one.
Comment 9 Fabio Durán Verdugo 2013-12-09 20:27:05 UTC 
update the version to 3.10.x
Comment 10 Michael Uphoff 2014-11-28 19:47:49 UTC 
This bug is still reproduceable with Version 3.12.0. Additionally, the CPU usage increases as soon as a search result is displayed.
Comment 11 Fabio Durán Verdugo 2015-02-10 20:26:11 UTC 
Update the version to 3.14.x 

(test with 3.14.1)
Comment 12 David King 2015-04-21 09:46:47 UTC 
I cannot reproduce this with Yelp 3.16.0 (and webkitgtk 2.4.8).
Comment 13 David Rodgers 2015-06-09 09:54:37 UTC 
Searching in yelp still causes bug for yelp 3.16.1 on latest Fedora.
Comment 14 Matej 2015-09-30 11:34:53 UTC 
The bug is still reproducible on Fedora 22, yelp-3.16.1-1.fc22.x86_64, webkitgtk3-2.4.9-1.fc22.x86_64.
Comment 15 Christian Stadelmann 2015-12-02 18:31:42 UTC 
Why is this bug report marked as obsolete? It surely isn't. This issue is still reproducible on a 3.18 gnome desktop.
Comment 16 Michael Catanzaro 2016-02-06 21:47:03 UTC 
(In reply to Christian Stadelmann from comment #15)
> Why is this bug report marked as obsolete? It surely isn't. This issue is
> still reproducible on a 3.18 gnome desktop.

I debugged this a bit recently. This issue is fixed in Yelp 3.18, but Fedora 23 shipped with Yelp 3.17.2 to avoid a particular regression. So obsolete really is the right status for this.

But, there is also a VERY similar issue, bug #761647.
Comment 17 Michael Catanzaro 2016-02-06 21:48:26 UTC 
To be clear, I can reproduce this issue in Yelp 3.17.2, but it got fixed during the port to WebKit2. It was pretty confusing because I thought for a while it was the same as bug #761647.
Comment 18 André Klapper 2016-09-05 10:49:51 UTC 
*** Bug 744636 has been marked as a duplicate of this bug. ***