GNOME Bugzilla – Bug 354823
Crash in gnome_vfs_get_volume_monitor
Last modified: 2006-10-17 14:49:39 UTC
Version: 2.15.9 What were you doing when the application crashed? Distribution: Gentoo Base System version 1.12.4 Gnome Release: 2.15.92 2006-09-01 (Gentoo) BugBuddy Version: 2.15.92 Memory status: size: 38502400 vsize: 0 resident: 38502400 share: 0 rss: 18604032 rss_rlim: 0 CPU usage: start_time: 1157651257 rtime: 0 utime: 115 stime: 0 cutime:108 cstime: 0 timeout: 7 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gedit' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1216588112 (LWP 11531)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 71822
Thread 1 (Thread -1216588112 (LWP 11531))
Thanks for taking the time to report this bug. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a description of how to reproduce this bug. You'll also need to add a stack trace; please see http://live.gnome.org/GettingTraces for more information about how to do so. It seems a crash in gnome-vfs or on the gnome-vfs backend of the file chooser.
*** Bug 354886 has been marked as a duplicate of this bug. ***
*** Bug 355022 has been marked as a duplicate of this bug. ***
*** Bug 355102 has been marked as a duplicate of this bug. ***
*** Bug 355076 has been marked as a duplicate of this bug. ***
All the duplicates of this crash happen on Gentoo. What optimisations did you use when you built GNOME libraries and dbus? Note that using optimisation higher than -O2 is not supported.
*** Bug 355001 has been marked as a duplicate of this bug. ***
note that it crashes in dbus
I suspect this crash is due to some problem introduced by the compiler when compiling with aggressive optimization switches. In fact all the crashes we are observing are on Gentoo.
*** Bug 355205 has been marked as a duplicate of this bug. ***
*** Bug 355403 has been marked as a duplicate of this bug. ***
*** Bug 355361 has been marked as a duplicate of this bug. ***
*** Bug 355603 has been marked as a duplicate of this bug. ***
Still, all duplicates are on Gentoo. Possibly NOTGNOME.
Dbus and gnome libs were compiled using the flags: -march=athlon64 -O2 -pipe as was everything else on the system, using gcc 4.1.1. I can confirm this crash happens 100% of the time I run gedit as root, but never seems to happen running as a normal user.
Also, the following warning appears when launching gedit (again, only as root): (gedit:31790): GnomeUI-WARNING **: While connecting to session manager: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed. And another warning upon trying to open a file, right before the crash: (gedit:31790): libgnomevfs-WARNING **: Failed to open session DBUS connection: No reply within specified time Volume monitoring will not work.
Might be a side effect of gnomevfs migration to D-Bus: you don't have a session daemon running for root when you use `sudo`.
*** Bug 355621 has been marked as a duplicate of this bug. ***
Hi, I'm also getting this. I'm also on Gentoo. I can recreate this easily and reliably in pretty much any program that uses a standard file chooser dialog. I haven't managed to test it as any user other than root. I have two systems that were compiled roughly as follows: Portage 2.1.1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17-gentoo-r7 i686) ================================================================= System uname: 2.6.17-gentoo-r7 i686 AMD Athlon(tm) 64 Processor 3400+ ccache version 2.4 [enabled] dev-util/ccache: 2.4-r2 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17 CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" LDFLAGS="-Wl,--as-needed" LINGUAS="en_GB en" MAKEOPTS="-j1" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_RSYNC_EXTRA_OPTS I've tried to cut this down to just the pertinent information. My other box was built with CFLAGS = CXXFLAGS = "-mtune=pentium4 -march=pentium4 -O2 -fomit-frame-pointer -pipe -msse3", since it's a dual-core Intel. The current version of dbus I'm using is 0.62. The issue goes away if I launch the affected program using dbus-launch. If this is a compilation issue, the two features of my build setup that cause me the greatest headaches are the LDFLAGS set to --as-needed (which should compile each binary pulling in only the libraries that are specifically called, rather than any that are mentioned) and the ccache (but this has only ever caused a couple of problems in the past). If there's any further information I can provide to help figure out this problem, please let me know, I'd really like to see it solved...
Also, is there any chance of re-opening this, or rephrasing the specific information that's required? At the moment, this bug is difficult to find (I expected it to be an open bug) and yet it appears quite a common one...
>(gedit:31790): libgnomevfs-WARNING **: Failed to open session DBUS connection: >No reply within specified time >Volume monitoring will not work. >The issue goes away if I launch the affected program using dbus-launch. this is a setup issue then, I strongly assume. dbus-launch sets the DBUS_SESSION_BUS_ADDRESS environment variable. However I cannot reproduce the crash unsetting DBUS_SESSION_BUS_ADDRESS but the last statement conveys to me that we seem to have a setup problem. The fact that this only affects Gentoo underlines this.
OK, unfortunately I don't know what the normal start-up procedure is for a program, so could someone not experiencing this issue post their experiences with the following: Start up X as a normal user. Start up gnome-terminal (probably run as a login shell) Launch gedit, click on open, have it all work fine. Then exit gedit, run "su -" and login as root. Ensure there is no dbus-session ("ps aux | grep dbus | grep root" should be empty). Then run gedit again, then click on open. What I'm interested in is whether in standard builds, dbus is automatically launched, whether the gnome-vfs still spits out the warning about dbus not being found. I'm also interested in what calls gnome-vfs attempts to make in volume_monitor_client_shutdown_private, since it seems clear these make dbus calls, which end up breaking:
+ Trace 72249
Having taken a quick dive into the source code, I can't figure out how dbus_connection_send_with_reply_and_block can be sent out, since the dbus_conn should always be NULL if there's no dbus-session running? If there is a dbus-session running, which one is it trying to latch onto? I also can't follow how gnome_vfs_volume_monitor_emit_pre_unmount ever gets called? Could someone with a bit more experience in the area look into the code and stacktrace to help trace the problem component please?
*** Bug 355735 has been marked as a duplicate of this bug. ***
*** Bug 355736 has been marked as a duplicate of this bug. ***
*** Bug 355794 has been marked as a duplicate of this bug. ***
*** Bug 355930 has been marked as a duplicate of this bug. ***
*** Bug 355925 has been marked as a duplicate of this bug. ***
*** Bug 355944 has been marked as a duplicate of this bug. ***
*** Bug 355949 has been marked as a duplicate of this bug. ***
*** Bug 356002 has been marked as a duplicate of this bug. ***
*** Bug 356123 has been marked as a duplicate of this bug. ***
CFLAGS="-march=athlon64 -O2 " CHOST="x86_64-pc-linux-gnu" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j3" #ACCEPT_KEYWORDS="~amd64" VIDEO_CARDS="vesa" INPUT_DEVICES="keyboard mouse joystick" LINGUAS="en" This is the important part of my make.conf. I also get this problem.... I've read through this and it seems that it has been nailed as a setup issue.. Is there anyway to contact the Gentoo Gnome team to see if they are aware of this problem? Or have they already been informed?
*** Bug 356262 has been marked as a duplicate of this bug. ***
*** Bug 356308 has been marked as a duplicate of this bug. ***
*** Bug 356313 has been marked as a duplicate of this bug. ***
*** Bug 356332 has been marked as a duplicate of this bug. ***
Given the sheer number of duplicates that are coming it, it would be worthwhile trying to track down this bug simply to ease the load on bugzilla. As such, I'd like to ask again that the status be reopened, so that we can get more people looking at the bug? It appears as though there's a spontaneous call to gnome_vfs_volume_monitor_emit_pre_unmount which shouldn't be possible without a dbus connection, yet it always seems to occur right before the crash, even though a session dbus isn't running. As soon as it is running it works fine (presumably because this call is working on a valid dbus conenction). Unfortunately, we're going to need a little help from someone who knows the code better to help understand why. As ever I'm happy to test out any patches or code modifications anyone is willing to offer that might fix this problem, and I'll report as much information as I can on the tests. I'd like to see a fix for this go into at least portage, if not upstream, as soon as possible...
There are about 30 duplicates of this bug and all on Gentoo May be the gentoo guys should try to give a look at it.
*** Bug 356472 has been marked as a duplicate of this bug. ***
*** Bug 356468 has been marked as a duplicate of this bug. ***
*** Bug 356526 has been marked as a duplicate of this bug. ***
*** Bug 356566 has been marked as a duplicate of this bug. ***
*** Bug 356771 has been marked as a duplicate of this bug. ***
*** Bug 357035 has been marked as a duplicate of this bug. ***
It would have been nice if at least one of these people had actually submitted a gentoo bug for this... At any rate, it's easily reproducable here, so I'll look into it.
Color me confused, but there doesn't appear to be any protection for lack of DBUS connection in gnome_vfs_volume_monitor_client_init(). I've added the tiny patch attached, and this problem goes away for me; gedit run via sudo workes fine, edits and changes files, and doesn't crash. I doubt this is the right solution, but why aren't others hitting this problem? It *should* happen anywhere there's no dbus connection? Is something supposed to be auto-spawning a dbus session when one doesn't exist that gentoo is missing?
Created attachment 73148 [details] [review] workaround for missing dbus session
*** Bug 357117 has been marked as a duplicate of this bug. ***
*** Bug 357339 has been marked as a duplicate of this bug. ***
*** Bug 357358 has been marked as a duplicate of this bug. ***
*** Bug 357356 has been marked as a duplicate of this bug. ***
*** Bug 358197 has been marked as a duplicate of this bug. ***
*** Bug 358889 has been marked as a duplicate of this bug. ***
gicmo, christian: this bites a lot of users. simple workaround attached, please take a look at it. marking this one as a GNOME 2.16.x target, too many dups.
Andre: I totally agree with you. Thanks for coming up with a patch. Let's decide Alex how exactly he wants the code to be laid out, though.
christian: thanks of the quick responses (in general). :-) i assume that you're going to poke alex as he isn't on the CC list, thanks in advance.
Created attachment 74119 [details] [review] prevent crashing when no session bus is running this patch (included in Mandriva Linux 2007.0) prevents crash when no session bus is running (for instance when logging on a system with ssh and running a gnome application there). It also disable the "failed to open dbus connection" warning since there is no point is giving this information to users (they won't be able to do anything for that). Since future dbus version will have autolaunch, if gnome-vfs requires such version, enabling back the warning will be interesting.
CC'ing alex to get one of these trivial patches in asap - too many crash reports already about this.
I commited Frederics patch. Thanks guys.
great, thanks for fixing this. :-)