Nautilus and Dbus errors
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GnomeVFS |
Fix Released
|
Medium
|
|||
gnome-vfs2 (Fedora) |
Fix Released
|
Medium
|
|||
gnome-vfs2 (Ubuntu) |
Fix Released
|
Low
|
Ubuntu Desktop Bugs | ||
nautilus (Baltix) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
hello,
when I launch Nautilus from enlightment, Volume monitoring doesn't work and network idem.
I receive somme messages like:
(nautilus:14549): libgnomevfs-WARNING **: Failed to open session DBUS connection: Failed to connect to socket /tmp/dbus-
Volume monitoring will not work.
14549: arguments to dbus_connection
This is normally a bug in some application using the D-Bus library.
14549: arguments to dbus_connection
This is normally a bug in some application using the D-Bus library.
** Message: Failed to close thumbnail pixbuf loader for /home/jux/
** Message: Failed to close thumbnail pixbuf loader for /home/jux/out.pnm: Format d'image non reconnu
** Message: Failed to close thumbnail pixbuf loader for /home/jux/
** Message: Failed to close thumbnail pixbuf loader for /home/jux/out.pnm: Format d'image non reconnu
(nautilus:14549): libgnomevfs-WARNING **: Failed to open session DBUS connection: Failed to connect to socket /tmp/dbus-
Volume monitoring will not work.
(nautilus:14549): libgnomevfs-WARNING **: Failed to open session DBUS connection: Failed to connect to socket /tmp/dbus-
Volume monitoring will not work.
(nautilus:14549): libgnomevfs-WARNING **: Failed to create service browser: Bad state
(nautilus:14549): libgnomevfs-WARNING **: Failed to create service browser: Bad state
(nautilus:14549): libgnomevfs-WARNING **: Failed to create service browser: Bad state
(nautilus:14549): libgnomevfs-WARNING **: Failed to create service browser: Bad state
(nautilus:14549): gnome-vfs-
Couldn't get main dbus connection: Failed to connect to socket /tmp/dbus-
Couldn't get main dbus connection: Failed to connect to socket /tmp/dbus-
Note: the original reporter indicated the bug was in package 'nautilus'; however, that package was not published in Baltix.
Changed in gnome-vfs: | |
status: | Unknown → Unconfirmed |
Changed in gnome-vfs2: | |
status: | Unknown → Rejected |
Changed in nautilus: | |
status: | Unconfirmed → Rejected |
Changed in gnome-vfs2: | |
status: | Rejected → Fix Released |
Changed in gnome-vfs: | |
status: | New → Fix Released |
Changed in gnome-vfs: | |
importance: | Unknown → Medium |
Changed in gnome-vfs2 (Fedora): | |
importance: | Unknown → Medium |
Description of problem:
If an application displays a GTK FileChooserDialog dialog when there is no DBus
daemon available it ends up trying to use a NULL DBus connection violating DBus
assertions. Fortunately our DBus builds have assertion checking enabled, if this
were turned off the app would likely trigger SEGV deferencing a null pointer.
(vfsdbus.py:3756): libgnomevfs-WARNING **: Failed to open session DBUS _send_with_ reply_and_ block() were incorrect, _send_with_ reply_and_ block() were incorrect,
connection: Unable to determine the address of the message bus (try 'man
dbus-launch' and 'man dbus-daemon' for help)
Volume monitoring will not work.
3756: arguments to dbus_connection
assertion "connection != NULL" failed in file dbus-connection.c line 2785.
This is normally a bug in some application using the D-Bus library.
3756: arguments to dbus_connection
assertion "connection != NULL" failed in file dbus-connection.c line 2785.
This is normally a bug in some application using the D-Bus library.
This can be reproduced with the following PyGTK code:
$ cat > vfsdemo.py <<EOF
#!/usr/bin/python
import gtk
fcdialog = gtk.FileChooser Dialog( "VFS demo",
None,
gtk. FILE_CHOOSER_ ACTION_ OPEN,
(gtk. STOCK_CANCEL, gtk.RESPONSE_ CANCEL,
gtk. STOCK_OPEN, gtk.RESPONSE_ ACCEPT) ,
None) BUS_ADDRESS= python vfsdbus.py
response = fcdialog.run()
EOF
$ DBUS_SESSION_
Version-Release number of selected component (if applicable): 2.16.0- 2.fc6 2.16.0- 1.fc6
libgnome-
gnome-vfs2-
dbus-0.92-1.fc6
How reproducible:
Always
Steps to Reproduce: BUS_ADDRESS variable
1. Unset the DBUS_SESSION_
2. Run an application which displays a FileChooserDialog
3. Watch console
Actual results:
DBUs assertion failures displayed
Expected results:
No error / failure messages shown.
At least the assertion failures need to be cleaned up, but I think it could be
desirable to hide this first raw DBus message from view too:
(vfsdbus.py:3756): libgnomevfs-WARNING **: Failed to open session DBUS
connection: Unable to determine the address of the message bus (try 'man
dbus-launch' and 'man dbus-daemon' for help)
It makes it look like a nasty application error (resulting in bogus application
bug reports), when in fact its perfectly legitimate to use GTK without DBus
present (eg, ssh'd to a box as root & running a GUI app). A simple 'DBus session
daemon not available, disabling volume monitoring' would be sufficient & much
less scary to the user than this.