GNOME Bugzilla – Bug 574444
recieving fd with wrong id on sync open
Last modified: 2013-01-02 16:12:04 UTC
Version: 0.11.6 What were you doing when the application crashed? Distribution: Gentoo Base System release 2.0.0 Gnome Release: 2.24.3 2009-01-26 (Gentoo) BugBuddy Version: 2.24.2 System: Linux 2.6.26-hardened-r1 #2 SMP PREEMPT Thu Sep 4 11:18:04 CDT 2008 i686 X Vendor: The X.Org Foundation X Vendor Release: 10503000 Selinux: Enforcing Accessibility: Disabled GTK+ Theme: Unity Icon Theme: gnome-alternative Memory status: size: 196124672 vsize: 196124672 resident: 87867392 share: 43151360 rss: 87867392 rss_rlim: 18446744073709551615 CPU usage: start_time: 1235891696 rtime: 5720 utime: 4812 stime: 908 cutime:0 cstime: 3 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/rhythmbox' [Thread debugging using libthread_db enabled] [New Thread 0xb65df720 (LWP 10386)] [New Thread 0xaca1bb90 (LWP 18064)] [New Thread 0xb27feb90 (LWP 18063)] [New Thread 0xb2fffb90 (LWP 18062)] [New Thread 0xb17fcb90 (LWP 18061)] [New Thread 0xafff9b90 (LWP 18060)] [New Thread 0xb07fab90 (LWP 18059)] [New Thread 0xb0ffbb90 (LWP 18058)] [New Thread 0xb1ffdb90 (LWP 15976)] [New Thread 0xb40d0b90 (LWP 10391)] 0xb7fba422 in __kernel_vsyscall ()
+ Trace 213238
Thread 9 (Thread 0xb1ffdb90 (LWP 15976))
The crash occurred inside gvfs, while doing a straightforward g_file_get_contents call on http://leoville.tv/podcasts/floss.xml
There are lots of parallel sync gvfs action, but each thread is using its own private thread-local connection. Yet when we open the file which is a 1) dbus send open message 2) recieve dbus reply, which on success has a counter on the number of the fd to recieve 3) on success retrieve the new fd, and verify that its the right one i.e. the third successful open will say fd_id == 3 and we verify that its the third call to recieve_fd on that connection. However, this assert fails, so we're either missed to recieve an fd or recieved one to many. I don't see how this could happen though. The connection is per-thread, so there are no races, and there are no exits between successful dbus reply and recieving the fd (2-3 above). Can you reproduce this? It would be interesting to see data->extra_fd_count at:
+ Trace 213288
(In reply to comment #2) > I don't see how this could happen though. It has happened to us in Maemo 5, too, now. My theory is that reply reordering can actually happen when _g_vfs_daemon_call_sync uses dbus_connection_send_with_reply_and_block. The other branch in _g_vfs_daemon_call_sync uses dbus_connection_dispatch which will make sure that any outstanding fds are read from the socket and that extra_fd_count is up-to-date when _g_vfs_daemon_call_sync returns. I'll try to concoct a fix for this.
Similar downstream bug report from evolution 2.32.2: https://bugzilla.redhat.com/show_bug.cgi?id=714967
This issue seems to happen when I mount a remote ssh folder on my local LAN and then connect to a VPN. This bug is happening as I write this, I cannot umount the ssh folder and every click on Evolution's "New Message", "Reply" or "Reply to All" makes it hang for 1 or 2 minutes before the new window appears. If I turn off the VPN, I still can't umount the ssh folder. Thank you for your time for reviewing this ticket.
I think the bug report, https://bugzilla.redhat.com/show_bug.cgi?id=716946 , is also related with this issue as the above comment by Milan Crha.
Can somebody please retest this with recent gvfs release, post-gdbus port, i.e. 1.13.4 and later? A lot has changed wrt opening files and transferring FDs, GDBus is generally more precise of message targetting.
As there are no new comments this seems to be fixed. Could it be closed?
Closing as per comment 8, considered it fixed by gdbus port. Feel free to reopen (and add proper repro steps) when you see the issue again.