Bug 206058 - App hangs in pthread lock when destroying gtk FileChooserDialog
App hangs in pthread lock when destroying gtk FileChooserDialog
Product: Fedora
Classification: Fedora
Component: libgnomeui (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Depends On:
Blocks: 206015
  Show dependency treegraph
Reported: 2006-09-11 15:13 EDT by Daniel Berrange
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-11 23:34:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
GDB backtrace from app (18.17 KB, text/plain)
2006-09-11 15:13 EDT, Daniel Berrange
no flags Details

  None (edit)
Description Daniel Berrange 2006-09-11 15:13:09 EDT
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


How reproducible:

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
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

  fcdialog = gtk.FileChooserDialog("Hang demo",
                                   (gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,
                                    gtk.STOCK_OPEN, gtk.RESPONSE_ACCEPT),
  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.
Comment 1 Daniel Berrange 2006-09-11 15:13:09 EDT
Created attachment 136030 [details]
GDB backtrace from app
Comment 2 Daniel Berrange 2006-09-11 17:49:16 EDT
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@imendio.com>

        * 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,
        (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
        (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
Comment 3 Matthias Clasen 2006-09-11 23:34:34 EDT
fixed in 2.16.0-2

Note You need to log in before you can comment on or make changes to this bug.