Red Hat Bugzilla – Bug 206058
App hangs in pthread lock when destroying gtk FileChooserDialog
Last modified: 2007-11-30 17:11:42 EST
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
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
Hang in deep in the destroy function chain
Dialog is destroyed normally
Demo program to reproduce:
fcdialog = gtk.FileChooserDialog("Hang demo",
response = fcdialog.run()
print "About to hide dialog"
print "About to destroy dialog"
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 <firstname.lastname@example.org>
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,
(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,
(create_folder_progress_cb): guard the file system during callback
(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
fixed in 2.16.0-2