GNOME Bugzilla – Bug 306162
"Find Files" Browse Window freezes desktop when in home folder with speech enabled
Last modified: 2005-10-05 15:57:56 UTC
Using latest internal linux build, srcore 0.11.1 Steps to reproduce: * Start up gnopernicus with speech enabled * Go to Launch -> Find Files * Enter a vlue into the "Name Contains" box * Tab twice to Browse Button and action it * In Browse window, hit spacebar to open up the focused "test1" folder. * When it's open, tab to "Cancel" button. At this stage, trying to tab again will not work because the window is frozen. The Desktop has also frozen so the user cannot quit out. The only way is to use the mouse and hit the X button at the top-right corner of Browse window and "Force Quit". This is obviously not an option to a blind speech user.
Gary, can you attach your stack trace here also? Thanks.
Also, the stack trace you attached to the internal bug is insufficient, it has no symbol data so I can tell nothing from it, really.
Created attachment 47133 [details] Stack Trace for Browse Window freezing
How would I get a stack trace that is sufficient?
I carried out the following steps to get stack trace: export DISPLAY=0.0 ps -ef |grep gnome-search-tool script crash1 gdb /usr/bin/gnome-search-tool <pid> <return> cont Go back to the desktop and perform the freeze and force quit. Go back to the virtual terminal. Type: where <Ctrl>+D to stop the script.
To start with, I'd advise carrying this out while running gnome-search-tool inside gdb to start with, from a console. If a segv occurs you'll get a stack trace.
I see, you said: "perform the freeze and force quit". But this isn't really the right thing to do - you are artificially forcing a quit after the problem has already occurred, and the stack trace you see doesn't necessarily reflect the root cause of the problem. It would be better to strace the relevant processes when the system is 'hung', to see if a deadlock can be identified. It seems that there is no "crash" until you forcibly try to get out of the situation by quitting.
I have managed to reproduce the problem. A segv/crash _does_ occur, though it was not clear from the description. I have seen a longer stack trace (though because I am using xterm I haven't been able to cut and paste it here yet).
Created attachment 47142 [details] [review] patch to fix patch fixes bug on my system. Still need to write ChangeLog entry.