Description of problem: Using the gtk.FileChooserDialog from Python with threading enabled, the application will hang wheen the 'destroy' method of the file chooser object is invoked. A GDB backtrace shows it waiting on a mutex lock deep in the VFS code - execute_vfs_callbacks_idle. If the call to gtk.gdk.threads_init() is removefd the hang no longer occurrs. Version-Release number of selected component (if applicable): Fedora Core rawhide as of Sep 11, 15:00 EDT libgnome-2.16.0-1.fc6.x86_64 libgnomeui-2.16.0-1.fc6.x86_64 gtk2-2.10.3-1.fc6.x86_64 pygtk2-2.9.6-2.fc6.x86_64 How reproducible: Always Steps to Reproduce: 1. Write code which creates a FileChooserDialog, run's the loop & then destroys it 2. Click the cancel / open button when the dialog is display 3. Actual results: Hang in deep in the destroy function chain Expected results: Dialog is destroyed normally Additional info: Demo program to reproduce: import threading import gobject import gtk gtk.gdk.threads_init() fcdialog = gtk.FileChooserDialog("Hang demo", None, gtk.FILE_CHOOSER_ACTION_OPEN, (gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, gtk.STOCK_OPEN, gtk.RESPONSE_ACCEPT), None) response = fcdialog.run() print "About to hide dialog" fcdialog.hide() print "About to destroy dialog" fcdialog.destroy() print "Everything done" The last message is never printed, geting stuck in destroy(). The stack trace from GDB is attached to this ticket. Assigned to 'libgnomeui' because that's where the last function call before pthread's is invoked from, but guess the problem could be anywhere in the PyGtk, GNOME, GTK stack.
Created attachment 136030 [details] GDB backtrace from app
Looking at the ChangeLog in libgnomeui-2.16.0, the very last / most recent entry is a change which introduced the function call where I'm seeing the deadlock: ======================== 2.16.0 =========================== 2006-09-02 Kristian Rietveld <kris> * file-chooser/gtkfilesystemgnomevfs.c (gtk_file_system_gnome_vfs_dispose), (queue_vfs_idle_callback), (gtk_file_system_gnome_vfs_init), (handle_cancel_operation_fn): remove pending execute_vfs_callbacks_idle and pending vfs async handles during dispose, execute all idle callbacks waiting to be run in the next idle, (gtk_file_system_gnome_vfs_get_folder), (gtk_file_system_gnome_vfs_cancel_operation), (gtk_file_systel_gnome_vfs_volume_mount), (execute_vfs_callbacks_idle), (queue_vfs_idle_callback): refactor to maintain a list of idle callbacks to call per file system instead of globally, guard the file system during callback invocation, (get_folder_file_info_callback), (get_file_info_callback), (create_folder_progress_cb): guard the file system during callback invocation, (gtk_file_folder_gnome_vfs_get_info): set GError if uri doesn't exist in the folder. This would certainly explain why it started occurring after upgrading libgnomeui to 2.16.0
fixed in 2.16.0-2