GNOME Bugzilla – Bug 480123
Crash from GTK's new search feature
Last modified: 2007-09-25 23:34:58 UTC
Steps to reproduce: 1. File -> Open 2. Pick the new 'search' item 3. Type in 'test' 4. Hit enter 5. Search results appear 6. Cancel the dialog Stack trace: System: Linux 2.6.22-fixdso #1 SMP Sat Aug 25 16:14:05 BST 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 10400000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: gnome Memory status: size: 188760064 vsize: 188760064 resident: 84791296 share: 32837632 rss: 84791296 rss_rlim: 4294967295 CPU usage: start_time: 1190657800 rtime: 96988 utime: 82402 stime: 14586 cutime:1960 cstime: 152 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/epiphany' Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb5ef38d0 (LWP 5408)] [New Thread 0xad649b90 (LWP 15775)] [New Thread 0xb0f97b90 (LWP 5538)] [New Thread 0xb1798b90 (LWP 5537)] [New Thread 0xb4bb4b90 (LWP 5514)] [New Thread 0xb53b5b90 (LWP 5473)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 165292
Thread 1 (Thread 0xb5ef38d0 (LWP 5408))
----------- .xsession-errors (28591 sec old) --------------------- (gnome-panel:4863): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x80ec958 (gnome-panel:4863): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x80ec958 (gnome-panel:4863): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x80ec958 (gnome-panel:4863): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x80ec958 (gnome-panel:4863): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x80ec958 (gnome-panel:4863): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x80ec958 (gnome-panel:4863): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x80ec958 (gnome-panel:4863): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x80ec958 -------------------------------------------------- Other information:
GtkFileChooser's search afaik is an interface for the default system indexer (e.g. beagle, tracker), and it might be his fault (or GTK's) rather than our. Anyway, I can't reproduce this on Gnome 2.20 + Beagle 0.2.18 + Gtk 2.12 (cancelling the dialog does what is expected), but I'll keep this open, maybe other people might reproduce it.
Ok, the interesting this is that I have neither tracker nor beagle installed. So I assume the crash is from the code in GTK that provides the fallback search method that is used in my case.
-> gtk+
Here's a similarly trigger crash from gedit-2.18 with gtk+-2.12 that has a wildly different backtrace but I think with more details. I think the key function names are just optimized out in case of the original report. As additional information, it continued to do I/O after the dialog was cancelled and the crash happened once it was done. So I think it simply doesn't cancel the I/O churn on cancel and then once it's done it accesses object that don't exist anymore as the dialog was closed meanwhile. Distribution: Gentoo Base System release 2.0.0_rc4-r1 Gnome Release: 2.18.3 2007-09-07 (Gentoo) BugBuddy Version: 2.18.1 System: Linux 2.6.22-gentoo-r6 #1 PREEMPT Fri Sep 7 23:54:26 EEST 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 10400000 Selinux: No Accessibility: Enabled GTK+ Theme: Clearlooks Icon Theme: gnome Memory status: size: 81539072 vsize: 81539072 resident: 19058688 share: 14503936 rss: 19058688 rss_rlim: 4294967295 CPU usage: start_time: 1190725526 rtime: 331 utime: 217 stime: 114 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/gedit' Using host libthread_db library "/lib/libthread_db.so.1". 0xb7fe1410 in __kernel_vsyscall ()
+ Trace 165351
No plugin installed in $HOME. Module versions: - glib 2.14.1 - gtk+ 2.12.0 - gtksourceview 1.8.5 - libgnomeui 2.18.1 - libglade 2.6.2 - libgnomeprintui 2.18.0 - gnome-vfs 2.18.1 - pygobject 2.12.3 - pygtk 2.10.6 - gnome-python 2.18.2 - gnome-python-desktop 2.18.0 - enchant 1.2.5 - iso-codes 0.58 Python module versions: - python 2.5.1 - pygtk 2.10.6 (GTK+ 2.12.0) - gnome-python 2.18.2 ----------- .xsession-errors --------------------- ** (bug-buddy:31554): WARNING **: AT_SPI_REGISTRY was not started at session startup. ** (bug-buddy:31554): WARNING **: IOR not set. ** (bug-buddy:31554): WARNING **: Could not locate registry Bonobo accessibility support initialized ** (bug-buddy:31554): WARNING **: AT_SPI_REGISTRY was not started at session startup. ** (bug-buddy:31554): WARNING **: IOR not set. ** (bug-buddy:31554): WARNING **: Could not locate registry checking for junk..? checking for junk..? --------------------------------------------------
That coincides with my observation: while the search was running, my hard disk was making clicking noises... even after I closed the dialog box, the clicking continued. Then the crash occured (and more clicking as gdb does loads of stuff that causes more I/O). :)
it seems that the simple search engine threads isn't stopped by the disposal of the file chooser dialog (and related search engine instance). I'm attaching a patch: could any of the commenters apply it to gtk+ trunk and try and reproduce (I don't have a non-libbeagle box to test on to)? thanks in advance.
Created attachment 96169 [details] [review] Cancel the active search on dispose the GtkSearchEngineSimple should cancel the active search (if any); the running thread will then free the data without invoking the search-finished signal.
(In reply to comment #6) > I'm attaching a patch: could any of the commenters apply it to gtk+ trunk and > try and reproduce (I don't have a non-libbeagle box to test on to)? thanks in > advance. It doesn't help any if applied on top of gtk+-2.12.0, leading to the same backtrace crash. After cancelling the dialog it churns still on I/O (as seen with the system monitor applet with visible color for I/O in CPU activity) and it crashes eventually. So unless there are other relevant fixes in trunk (I didn't see any), this patch doesn't seem to solve it.
the I/O churning is inevitable with the simple search engine implementation: it's nftw() in a thread, and that can only be cancelled when it reaches the batch size (500 items returned). we could lower the threshold and see what happens. with the patch I'm attaching now, I wasn't able to trigger the segfault after cancelling a search, using the tests/testfilechooser test unit.
Created attachment 96181 [details] [review] stop the search engine implementation when disposing the file chooser this patch forces to stop the search engine implementation when disposing the file chooser default implementation. it also cancels the search internally when disposing the instance in the simple search engine implementation.
(In reply to comment #9) > the I/O churning is inevitable with the simple search engine implementation: > it's nftw() in a thread, and that can only be cancelled when it reaches the > batch size (500 items returned). we could lower the threshold and see what > happens. No, it was a different problem. It didn't stop doing more batches before and probably went on for until the whole home dir (or whatever it's scanning) was done as it went on for some 20-40 seconds, after which it hit the crash. Now with the latest patch it cancels I/O within a second of cancelling the dialog. > with the patch I'm attaching now, I wasn't able to trigger the segfault after > cancelling a search, using the tests/testfilechooser test unit. Seems to fix that particular crash indeed :)
thanks for testing. committed to trunk. 2007-09-25 Emmanuele Bassi <ebassi@gnome.org> Fixes for bug #480123. * gtk/gtksearchenginesimple.c: (gtk_search_engine_simple_dispose), (search_thread_done_idle): Cancel the file tree walking thread when disposing the search engine implementation. * gtk/gtkfilechooserdefault.c (search_stop_searching): Forcibly stop the search engine implementation when stopping the search, instead of just unreffing the object.
Thanks. I have included the patch from attachment into Gentoo Linux gtk+ package until 2.14.1 is released.