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 601048 - Segfaults when typing too fast in the search box
Segfaults when typing too fast in the search box
Status: RESOLVED FIXED
Product: devhelp
Classification: Applications
Component: General
0.23
Other Linux
: High critical
: ---
Assigned To: devhelp-maint
devhelp-maint
: 601972 601973 601974 603394 618636 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-11-07 08:21 UTC by Зоран Рилак
Modified: 2010-05-14 14:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Gdb trace of lt-devhelp at the time of crash when typing too fast in the search box (12.38 KB, text/plain)
2009-11-13 02:45 UTC, Зоран Рилак
Details
trace from git master (17.56 KB, text/plain)
2009-12-03 20:47 UTC, Jonathon Jongsma
Details

Description Зоран Рилак 2009-11-07 08:21:07 UTC
Apparently one has to take it easy with Devhelp :)

1. Type "gtk_drag_finish" in the search box, really fast.  You need to type it in under 2 seconds.
2. Devhelp segfaults around the "inish" part.

This only happens intermittently.  I've been getting about 50% success rate at reproducing it.
Comment 1 Frederic Peters 2009-11-07 08:38:25 UTC
Without a stack trace from the crash it's very hard to determine what caused it.

Can you get a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!

Also, could you check with devhelp 2.28.1.
Comment 2 Зоран Рилак 2009-11-13 02:45:59 UTC
Created attachment 147626 [details]
Gdb trace of lt-devhelp at the time of crash when typing too fast in the search box
Comment 3 Зоран Рилак 2009-11-13 02:46:48 UTC
I admit I know nil about how to use gdb, so I followed through the commands as outlined here: https://wiki.ubuntu.com/Backtrace

I ran the lt-devhelp binary as that's the one that devhelp shell script runs.

Devhelp 2.28.0.1, GLib 2.22.2 (Ubuntu patched), GTK+ 2.18.3-1.
Comment 4 Frederic Peters 2009-11-13 09:34:33 UTC
Thanks, I'll get something out of it.
Comment 5 Зоран Рилак 2009-11-13 09:44:34 UTC
If I can be of any further assistance, you have my meagre talents and abundant time at your disposal.

Also, if you need me to reproduce it and catch trace in some other way, let me know.
Comment 6 Frederic Peters 2009-11-15 22:11:06 UTC
I just pushed a change wrt threads, could you try building devhelp from git and see if it fixes this bug for you?
Comment 7 Frederic Peters 2009-11-15 22:11:46 UTC
*** Bug 601974 has been marked as a duplicate of this bug. ***
Comment 8 Зоран Рилак 2009-11-15 22:28:49 UTC
git head now displays a red error bar "Error opening the requested link." when it would crash previously (I think).  The bar isn't very helpful; I haven't selected any links yet, I am only typing in the search box, and it did manage to crash once the first time I tried it, but I couldn't reproduce afterwards.  Overall it seems a lot more stable.

I'll play around more with it and post a trace if I can get it to crash again.  Thanks for your work, Frederic!
Comment 9 Frederic Peters 2009-11-30 17:08:37 UTC
*** Bug 603394 has been marked as a duplicate of this bug. ***
Comment 10 Jonathon Jongsma 2009-12-03 20:47:41 UTC
Created attachment 149036 [details]
trace from git master

I can still reproduce this from git master.  Full trace attached.  short version:

Thread 1 (Thread 0x7ffff7fbc7f0 (LWP 30947))

  • #0 queryInfoCallback
    at WebCore/platform/network/soup/ResourceHandleSoup.cpp line 844
  • #1 complete_in_idle_cb_for_thread
    at gsimpleasyncresult.c line 650
  • #2 g_main_dispatch
    at gmain.c line 1960
  • #3 IA__g_main_context_dispatch
    at gmain.c line 2513
  • #4 g_main_context_iterate
    at gmain.c line 2591
  • #5 IA__g_main_loop_run
    at gmain.c line 2799
  • #6 IA__gtk_main
    at gtkmain.c line 1217
  • #7 main
    at dh-main.c line 299

Comment 11 Frederic Peters 2009-12-03 21:10:01 UTC
Could you try with a newer webkit version (ideally trunk) ?
Comment 12 Gustavo Noronha (kov) 2009-12-09 22:53:56 UTC
I think this has been fixed by this commit: http://trac.webkit.org/changeset/51380

webkit 1.1.17 should have no problems here.
Comment 13 Gustavo Noronha (kov) 2009-12-09 22:56:14 UTC
*** Bug 601972 has been marked as a duplicate of this bug. ***
Comment 14 Jonathon Jongsma 2009-12-09 22:57:02 UTC
I can confirm that after upgrading to 1.1.17, the segfaults seem to have stopped.
Comment 15 Frederic Peters 2009-12-09 23:00:08 UTC
Thanks Gustavo! I was now looking for the webkit bug number but then I received notification you found and closed it, thanks again, keep rocking!
Comment 16 Frederic Peters 2009-12-15 21:57:30 UTC
*** Bug 601973 has been marked as a duplicate of this bug. ***
Comment 17 Frederic Peters 2010-05-14 14:47:18 UTC
*** Bug 618636 has been marked as a duplicate of this bug. ***