GNOME Bugzilla – Bug 351666
Assertion failed (crash) in gtk_file_chooser_default_should_respond
Last modified: 2011-02-04 16:10:42 UTC
What were you doing when the application crashed? Saving a blank new file. ^s -> "folder /tmp/something does not exist", and the save as dialog had a blank folder select box (didn't look what was in the dropdown) type "~/documents/", hit enter -> pauses, probably waiting for disk click cancel -> still waiting, then after a bit the crash dialog comes up Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.15.91 2006-08-08 (Ubuntu) BugBuddy Version: 2.15.90 Memory status: size: 126423040 vsize: 0 resident: 126423040 share: 0 rss: 44957696 rss_rlim: 0 CPU usage: start_time: 1155333141 rtime: 0 utime: 98856 stime: 0 cutime:94873 cstime: 0 timeout: 3983 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gedit' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1226499904 (LWP 15759)] [New Thread -1263137888 (LWP 15924)] (no debugging symbols found) 0xffffe410 in __kernel_vsyscall ()
+ Trace 70558
Thread 1 (Thread -1226499904 (LWP 15759))
Thanks for taking the time to report this bug. It seems a crash in the file chooser so I'm going to move this bug to gtk+. The steps to reproduce the crash are not very clear to me. In particular it is not clear to me how you got the "folder /tmp/something does not exist" message. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
steps to reproduce: $ mkdir /tmp/foo $ touch /tmp/foo/bar $ gedit /tmp/foo/bar & <wait for gedit window to open> [whether you close the "bar" tab here doesn't matter] $ rm -r /tmp/foo <In gedit window, ^n ^s to open and save a new file> "The folder contents could not be displayed" "error accessing 'file:///tmp/foo': File not found" <click "ok"> [the "save in folder" bar is blank, leave it like that] <type *anything* in the "name" field (ex: foo, /tmp/foo, ~/bar, ~/bar/) > <press enter or click "save"> **crash** *************************************************************************** Backtrace with some -dbg libraries: libglib2.0-0-dbg libgtk2.0-0-dbg libgnomeui-0-dbg . I don't seem to have a -dbg package for gedit itself. Backtrace was generated from '/usr/bin/gedit' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1226266432 (LWP 24521)] [New Thread -1263572064 (LWP 24528)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 70672
Thread 1 (Thread -1226266432 (LWP 24521))
Thanks for the great reply. I can reproduce the crash now. On the stack trace I get: Gtk-ERROR **: file gtkfilechooserdefault.c: line 7570 (gtk_file_chooser_default_should_respond): assertion failed: (path != NULL) Here a stacktrace with all the debugging symbols (using gedit and gtk+ from CVS HEAD): Backtrace was generated from '/opt/gnome/gnome-216/INSTALL/bin/gedit' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1224603968 (LWP 2033)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 70674
Thread 1 (Thread -1224603968 (LWP 2033))
This seems to happen because: 1. gedit sets a current folder (which starts an async operation to verify whether the folder exists) 2. Meanwhile gtk_file_chooser_default_map() is called and notices that a current folder verification is in progress (usually the map function sets the current folder to the current working directory if there's no folder given to display) 3. The operation started in 1) is done, and the folder doesn't exist. The file chooser appears without a current folder and pressing save causes the assert to be triggered. One solution might be to have update_current_folder_get_info_cb() set the current folder to the current working directory if the folder which we were requested to set doesn't exist and if no current folder is currently set. Is this a nice solution? (It does sound reasonable to me and I tried it locally, and it fixes the problem).
I think this is a duplicate of #350988
*** This bug has been marked as a duplicate of 350988 ***
*** Bug 375430 has been marked as a duplicate of this bug. ***
*** Bug 375177 has been marked as a duplicate of this bug. ***
*** Bug 375630 has been marked as a duplicate of this bug. ***
*** Bug 404813 has been marked as a duplicate of this bug. ***
*** Bug 404869 has been marked as a duplicate of this bug. ***
*** Bug 404882 has been marked as a duplicate of this bug. ***
*** Bug 405258 has been marked as a duplicate of this bug. ***
*** Bug 406375 has been marked as a duplicate of this bug. ***
*** Bug 406308 has been marked as a duplicate of this bug. ***
*** Bug 407401 has been marked as a duplicate of this bug. ***
*** Bug 408246 has been marked as a duplicate of this bug. ***
*** Bug 410151 has been marked as a duplicate of this bug. ***
*** Bug 413450 has been marked as a duplicate of this bug. ***
*** Bug 418252 has been marked as a duplicate of this bug. ***
*** Bug 420455 has been marked as a duplicate of this bug. ***
*** Bug 424803 has been marked as a duplicate of this bug. ***
*** Bug 427439 has been marked as a duplicate of this bug. ***
*** Bug 427904 has been marked as a duplicate of this bug. ***
*** Bug 428971 has been marked as a duplicate of this bug. ***
*** Bug 428713 has been marked as a duplicate of this bug. ***
*** Bug 430581 has been marked as a duplicate of this bug. ***
*** Bug 431351 has been marked as a duplicate of this bug. ***
*** Bug 431263 has been marked as a duplicate of this bug. ***
*** Bug 436736 has been marked as a duplicate of this bug. ***
*** Bug 448244 has been marked as a duplicate of this bug. ***