Qt apps often fail to start from file manager

Bug #1096289 reported by Alexei Kitaev on 2013-01-05
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
qt4-x11 (Ubuntu)
Undecided
Unassigned

Bug Description

DistroRelease: Ubuntu 12.10

Okular (and also Texworks) sometimes fail to start when opening a pdf file from file manager or Thunderbird. The program sleeps in background and has to be killed. This behaviour is highly unpredictable, but there are some patterns:
1) The error never occurs when Okular is called from the terminal.
2) The second time the file usually opens, but after closing and reopening the Nautilus window the problem recurs. Sometimes it's the other way around: files stop opening, but closing the Nautilus window helps.
3) The problem is more severe under Cinnamon/Nemo than under the default Ubuntu desktop.

I tried to call Okular from a script rather than directly. Here are some findings:
1) Okular works when the script is called from terminal but (sometimes) fails when it is called from file manager, although the working directory and environment variables are exactly the same.
2) Unsetting DBUS_SESSION_BUS_ADDRESS, GNOME_DESKTOP_SESSION_ID, or UBUNTU_MENUPROXY makes it work.
3) Introducing a delay (sleep 5) also seems to help.

Alexei Kitaev (aykitaev) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1096289/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Alexei Kitaev (aykitaev) on 2013-01-05
affects: ubuntu → qt4-x11 (Ubuntu)

I would like to confirm that I am seeing a similar bug with Qt programs. In my case I am not using Okular or Texworks, but Qt Creator exhibits this behavior when launching from the main menu, and my own custom Qt program also exhibits the behavior when launched from within Qt Creator itself and when launched from the file manager. As Alexei noted, it never occurs when launching from a terminal, and only intermittently occurs when launched from within the GUI. Qt Creator may open successfully some number of times and then the next time it hangs without showing a window and has to be killed from a terminal. I can't seem to find any logged messages indicating that something is going wrong.

Download full text (7.2 KiB)

This looks to be a race condition before QApplication() is finished. The following is a stack trace (missing a few debug symbols) from a hung program. I notice the call to g_bus_get_sync near the top of the stack, which a quick search reveals is related to the DBus integration. Also possibly related to or the same bug as Bug #1115647

#0 0x00007f33bddfb89c in __lll_lock_wait ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f33bddf709b in _L_lock_1006 ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f33bddf701c in pthread_mutex_lock ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f33bcb54e21 in g_mutex_lock (mutex=mutex@entry=0x164f1c0)
    at /build/buildd/glib2.0-2.34.1/./glib/gthread-posix.c:208
#4 0x00007f33b6824c2d in initable_init (initable=0x164f1a0, cancellable=0x0,
    error=0x0) at /build/buildd/glib2.0-2.34.1/./gio/gdbusconnection.c:2527
#5 0x00007f33b68255c1 in g_bus_get_sync (bus_type=<optimized out>,
    cancellable=0x0, error=0x0)
    at /build/buildd/glib2.0-2.34.1/./gio/gdbusconnection.c:6882
#6 0x00007f33b0e20518 in ?? ()
   from /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
#7 0x00007f33bc1d898f in g_type_create_instance (type=<optimized out>)
    at /build/buildd/glib2.0-2.34.1/./gobject/gtype.c:1890
#8 0x00007f33bc1bd288 in g_object_constructor (type=<optimized out>,
    n_construct_properties=0, construct_params=0x0)
    at /build/buildd/glib2.0-2.34.1/./gobject/gobject.c:1854
#9 0x00007f33bc1bed41 in g_object_newv (
    object_type=object_type@entry=23889072, n_parameters=n_parameters@entry=0,
    parameters=parameters@entry=0x0)
    at /build/buildd/glib2.0-2.34.1/./gobject/gobject.c:1637
#10 0x00007f33bc1bf38c in g_object_new (
    object_type=object_type@entry=23889072,
    first_property_name=first_property_name@entry=0x0)
    at /build/buildd/glib2.0-2.34.1/./gobject/gobject.c:1547
#11 0x00007f33b67bff11 in try_implementation (extension=<optimized out>,
    verify_func=verify_func@entry=0x7f33b67e8a30 <g_vfs_is_active>)
    at /build/buildd/glib2.0-2.34.1/./gio/giomodule.c:645
#12 0x00007f33b67c00a0 in _g_io_module_get_default (
    extension_point=extension_point@entry=0x7f33b685cb8c "gio-vfs",
    envvar=envvar@entry=0x7f33b6865222 "GIO_USE_VFS",
    verify_func=verify_func@entry=0x7f33b67e8a30 <g_vfs_is_active>)
    at /build/buildd/glib2.0-2.34.1/./gio/giomodule.c:742
#13 0x00007f33b67e8e6e in g_vfs_get_default ()
    at /build/buildd/glib2.0-2.34.1/./gio/gvfs.c:199
#14 0x00007f33b67ac6ae in g_file_new_for_path (
    path=0x16ba9b0 "/home/hunter/.config/ibus/bus/462ed6a22686e37540be4d5f51016f7c-unix-0") at /build/buildd/glib2.0-2.34.1/./gio/gfile.c:6092
#15 0x00007f33b1064baa in ?? () from /usr/lib/x86_64-linux-gnu/libibus-1.0.so.0
#16 0x00007f33bc1d898f in g_type_create_instance (type=<optimized out>)
    at /build/buildd/glib2.0-2.34.1/./gobject/gtype.c:1890
#17 0x00007f33bc1bd288 in g_object_constructor (type=<optimized out>,
    n_construct_properties=0, construct_params=0x0)
    at /build/buildd/glib2.0-2.34.1/./gobject/gobject.c:1854
#18 0x00007f33b1062b45 in ?? () from /usr/lib/x86_64-linux-gnu/libibus-1.0.so.0
#19 0x00007f33bc1bed41 in g_object_...

Read more...

As a temporary workaround, installing package qt4-qtconfig and selecting the Plastique style in qtconfig appears to fix the deadlocking behavior, though this does cause the program appearance to change.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in qt4-x11 (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers