GNOME Bugzilla – Bug 347467
Search function crashes Yelp if beagled not launched
Last modified: 2006-08-28 13:56:13 UTC
Steps to reproduce: 1. launch yelp 2. do not launch beagled 3. search anything Stack trace: Other information: yelp 2.15.4 (compiled with beagle support) beagle 0.2.7 mono 1.1.16.1 gnome 2.15.4 Everything compiled from sources.
Thanks for the bug report. Without a stack trace from the crash it's very hard to determine what caused it. Can you provide us with one? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
I wish I could... But when I "run" Yelp from gdb, it crashes right away: (gdb) run Starting program: /usr/bin/yelp [Thread debugging using libthread_db enabled] [New Thread -1228814672 (LWP 6204)] [New Thread -1231307856 (LWP 6209)] [New Thread -1265337424 (LWP 6210)] Detaching after fork from child process 6211. Program received signal SIG33, Real-time event 33. [Switching to Thread -1265337424 (LWP 6210)] 0xffffe410 in ?? () (staktrace uncomplete) This is rather strange. Is there something I should do from gdb ?
Hi, The SIG33 is a known {problem,feature} due to yelp using gnomevfs. To get a proper stacktrace when running yelp under gdb you have to use the command: handle SIG33 nostop noprint pass at the gdb prompt before running the program.
Ok, thanks ! Here it is: Starting program: /usr/bin/yelp [Thread debugging using libthread_db enabled] [New Thread -1229453648 (LWP 11687)] [New Thread -1231946832 (LWP 11690)] [New Thread -1265976400 (LWP 11691)] Detaching after fork from child process 11692. [New Thread -1276118096 (LWP 11696)] (yelp:11687): Yelp-WARNING **: beagled not running, using basic search support. Detaching after fork from child process 11703. Detaching after fork from child process 11706. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1229453648 (LWP 11687)] 0xb6d08c43 in strchr () from /lib/libc.so.6
+ Trace 69324
Thread 1 (Thread -1229453648 (LWP 11687))
Does this happen for every search you perform, or only for specific strings? Looking at the code, it appears the crash is happening while processing man page results [1]. Could you possibly run the command: apropos "<search terms>" from the command line and paste the results in the bug report? Thanks [1] Althought, I'm not certian of this as the stack trace seems a little stange in that it is calling strchr instead of strstr. It is probably that strstr calls strchr internally, but strstr not showing up in the stack trace makes me slightly nervous.
It happens for every search I have performed. I've just tried it with... apropos. But indeed, it seems to be connected to processing man pages. I ran 'apropos' on the string "apropos". It returned an intriguing "nothing appropriate". So I ran makewhatis to rebuild whatis databases. apropos returned "apropos (1) - search the whatis database for strings" and yelp doesn't crash anymore. Good. Strange thing is tha all this was triggered by not running beagle... Nevertheless, yelp should probably be less nervous about missing whatis database. I'm having a look at yelp's code if I can do something about it. But you'll be probably waaaay more efficient than me about this.
Created attachment 70571 [details] [review] search-crasher.patch This should fix this.
I can confirm the crash with 2.15.5 when beagle search is disabled and previously posted oneliner fixed this. Here's my stacktrace: (gdb) back
+ Trace 70145
*** Bug 351119 has been marked as a duplicate of this bug. ***
"I can confirm the crash with 2.15.5 when beagle search is disabled and previously posted oneliner fixed this." I don't quite follow you here. Are you saying that this patch fixes the problem with 2.5.15? If so then perhaps Don can go ahead and apply it.
Yep, my patch fixes it.
Thanks. I've committed the patch. Closing. 2006-08-16 Don Scorgie <dscorgie@cvs.gnome.org> * src/yelp-search-pager.c: Fix crash when apropos goes nuts (bug #347467) Patch from Priit Laes
*** Bug 352467 has been marked as a duplicate of this bug. ***