GNOME Bugzilla – Bug 751130
GtkFileChooser recursive search hangs
Last modified: 2015-06-19 00:39:37 UTC
Created attachment 305505 [details] Backtrace of hang Since 3.17.something, recursive search in the file chooser sometimes hangs the UI thread. Sometimes the application recovers after a second or so, but sometimes it just remains frozen for the duration of my patience. Here's a stacktrace of gedit 3.16.2 hung (it's running in my jhbuild environment with GTK+ master). The UI was totally unresponsive for about 15 seconds prior to my attaching gdb, after searching for "aaaaaaaaaaaaaaaaaaaaa" in my WebKit directory. The hang doesn't occur reliably, but I've found that typing a bunch of aaaaaaaaaaaa characters, backspacing a bunch, then typing more aaaaaaaaaaaaa characters, and repeating will eventually cause it to hang. Looking at the backtrace, I guess big GLists are being sorted on the UI thread. Surprise: after executing 'gdb c' the application unexpectedly recovered immediately and displayed No Files Found.
Created attachment 305506 [details] Backtrace #2 Another backtrace of a different instance of the hang. The backtraces are the same after the call to g_queue_sort (frame #1 in the second backtrace, frame #14 in the first backtrace).
any idea how long that thread pool task queue is at that point ?
Turns out to be very easy to reproduce by typing a bunch of a characters and then backspacing. Usually hangs on the first or second backspace of the first or second attempt. Note that I have hundreds of thousands of files in my home directory (curse of the browser developer). (In reply to Matthias Clasen from comment #2) > any idea how long that thread pool task queue is at that point ? Looks like 37787 (minus a very small number of waiting threads) (gdb) frame 9
+ Trace 235182
func=0x7fa880c8efc1 <g_task_compare_priority>, user_data=0x0) at gasyncqueue.c:783 783 g_queue_sort (&queue->queue, (gdb) print queue->queue.length $1 = 37787
I haven't reproduced this here yet. Are you using tracker, or is this just the simple search engine ? One thing is clear: Resorting the potentially long list when we know that just one item has changed is wasteful. In this case, we could simply move the cancelled task to the front of the queue and keep the list sorted.
I'm using tracker.
filed bug 751160 for the gtask aspect of this.
I've pushed some changes that have greatly reduced the overhead on my system - please reopen if you still see hangs.
I haven't been able to make it hang since building with your changes. I think it's good now. Thanks!