Hi, I'm the original reporter of https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/235326 - here's a new valgrind log with more debug symbols loaded.

Created attachment 112154 [details]
valgrind log with more symbols

I've been experiencing the same problem for since I started using Ubuntu (version 8.04). I just want to mention how I always experience the problem just in case it offers some clues:

1. Make a Samba share on another server. Mine are unpublished i.e. you don't see them when browsing the network, but you can "cd" and log into them after which they become visible in Nautilus.
2. Use Gnome Commander to navigate via the ~/.gvfs directory to the samba server and open a source code file in gedit.
3. Edit and save the file.

After a couple of saves at most you get a "Transport endpoint is not connected" error and an "ls -al" of the .gvfs directory returns this:
d????????? ? ? ? ? ? .gvfs

In /var/log/messages you see this:
Jun 28 18:57:19 Green732 kernel: [ 8748.661968] gvfs-fuse-daemo[6048]: segfault at 0800007a eip b7dec540 esp b740d0ac error 4

I'm running a i386 system and all packages are up to date (2008-07-01).

Oh yes, gvfs-fuse-daemon still crashes just as frequently in my case using the hack mentioned above of adding the -s argument to gvfs-fuse-daemon.

The problem has nothing to do with Gnome Commander. I tried editing files by navigating via the .gvfs directory using Nautilus and I experienced the same problems. However, if I use Nautilus to navigate via my bookmarks or "Connect to server..." with service type "Windows share" then the problem doesn't occur. So I assume the problem has something to do with navigating via the .gvfs directory only.

Created attachment 114586 [details] [review]
Patch that makes sure freed main_loop structures are not used.

I'm unsure if this is related to this, but the comments about the successful use a single threaded version of gvfs-fuse-daemon makes me wonder.

There is another issue with this code

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/235698

which is related to the calling of the vfs_destroy function after the threads have exited and have freed the subthread_main_loop structure.  The vfs_destroy function then calls g_main_loop_quit on the freed structure with the natural consequences.

This patch checks to see if the subthread_main_loop is running and only calls g_main_loop_quit if it is.  

It has knocked that other bug on the head, perhaps it works for this one too?

I'm the bug reporter...

I was just about to install packages with these patches applied when I tried to re-verify the original bug.

With the 0.2.5 version [1] of gvfs-fuse, I cannot reproduce the bug - it now runs perfectly stable for me in the default multi-threaded mode even when doing a copy of remote files to the same remote share - something that would always kill gvfs-fuse.

Can anyone else confirm this?

[1] 0.2.5-0ubuntu1 pushed to Ubuntu hardy-proposed on 30 Jun 2008

I don't have a SMB share to try this on.  But the code that causing the dying DBUS instance hasn't changed in the vanilla 0.2.5 version.  

On closer inspection (less tired, etc.) of the above logs, the crash occurs in a completely different function.  So the patch I submitted won't fix anything.    

==6174==    by 0x804BCEF: vfs_write (gvfsfusedaemon.c:1275)

Also, the diff of gvfsfusedaemon from 0.2.4 to 0.2.5 is empty.

Actually, this looks like it could have been a bug in glib.  

What version of glib were you using before?
What version are you running now?

Hm, reading the dates on the Ubuntu changelog for glib-2.0-0 shows that I would have been using 2.16.3-1ubuntu1 when this bug was reported.

There were a couple of subsequent Ubuntu-local patches for 2.6.13, with 2.6.14 appearing on 3rd July.

I can only assume that one of crashes fixed by that release also positively affected the fuse daemon. Hurrah for that.

Again, can anyone else confirm or deny that the problem has been resolved?

Austin: Which GLib bug are you referring to?

I just checked again and it's still crashing within 5 minutes of me opening a file in gedit and then saving it just a few times.
My Ubuntu 8.04 is up to date with these package versions (if relevant):
gvfs-fuse 0.2.4-0ubuntu1

Craig: Please enable the 'hardy-proposed' repository, update all packages and then log out + in. Then retry your tests.

System -> Administration -> Software Sources -> Updates

and select 'Proposed Updates'

I just updated all my packages to 'hardy-proposed'.
My gvfs-fuse version is now 0.2.5-0ubuntu1
But alas, the first file save I did in gedit cause gvfs-fuse-daemon to croak.

Craig: Sorry to sound like telephone tech support, but did you log out/in or reboot in between? I don't think the gvfs daemons restart themselves on upgrade.

Craig: Ignore me. I just tried gedit to a text file on ~/.gvfs/share on server/ .. saved it.. fine... edited... saved.. gedit locked up and then refreshing ~/.gvfs caused errors. No hint of a segfault in 'dmesg' output.. but the gvfs-fuse-daemon process is gone.

I'll see if I can whip up some backtraces or determine if the patches in this thread help any.

Gavin:
I did reboot. Anyway I rebooted once more and tried again. This time it croaked on the 2nd file save (so it seems to happen only when writing files but I'm not 100% sure yet I'll need to test that more if necessary). This is what ends up in /var/log/messages:
Jul 16 22:59:10 Green732 kernel: [  183.456082] gvfs-fuse-daemo[6044]: segfault at 20686381 eip b7dc5a04 esp b7c080d8 error 4

Created attachment 114682 [details]
New Backtrace

Reproducing the bug is easy, as per Craig. Just use gedit to save a file a few times on a ~/.gvfs/ resource. I've never been able to save more than thrice without a segfault.

gvfs-fuse-daemo[7477]: segfault at 0000097d eip b7d774f6 esp b7398068 error 4

I just tested various other text editors (nano, jedit, scite, anjunta, gphpedit) over the ~/.gvfs/ path  and none of them cause gvfs-fuse-daemon to crash when saving. So it seems like gedit's save function is tickling the file system in a way that other editors don't, triggering a gvfs-fuse-daemon segfault.

For Windows there's a nice tool to monitor this stuff: filemon by sysinternals. It would be useful to monitor these editors with something similar for Linux if something like that exists.

Does anyone have a core file for this crash?

My patch only touches vfs_destroy code.  The problem is clearly in vfs_write or further down the chain.  

The only thing further down the chain is glib, hence I was wondering if this might actually be an obscure glib bug.  I haven't gone searching to see if I can find what crashes in the code.

Also, not being able to recreate it is a problem.  Is there a way of setting up a loopback smb filesystem somehow?

I just ran it in foreground mode and got this additional output below when it crashed on a gedit save. It's mumbojumbo to me but may mean something to you. I don't see any core dump files. I can't use systemtap because Ubuntu doesn't have debuginfo in the kernel.
/usr/bin/fusermount -zu ~/.gvfs
/usr/lib/gvfs/gvfs-fuse-daemon -f ~/.gvfs

*** glibc detected *** /usr/lib/gvfs/gvfs-fuse-daemon: corrupted double-linked list: 0x0808f788 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7cb7d81]
/lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x8d)[0xb7cb8cad]
/usr/lib/libglib-2.0.so.0(g_malloc+0x2d)[0xb7e52dcd]
/usr/lib/libgio-2.0.so.0(g_themed_icon_new_from_names+0x35)[0xb7f38b35]
/usr/lib/gio/modules/libgvfsdbus.so[0xb6bbe084]
/usr/lib/gio/modules/libgvfsdbus.so[0xb6bbe1a0]
/usr/lib/gio/modules/libgvfsdbus.so[0xb6bada7c]
/usr/lib/libgio-2.0.so.0(g_file_query_info+0x90)[0xb7f21c50]
/usr/lib/gvfs/gvfs-fuse-daemon[0x804cc52]
/usr/lib/libfuse.so.2(fuse_fs_getattr+0x42)[0xb7dca532]
/usr/lib/libfuse.so.2[0xb7dcb3ae]
/usr/lib/libfuse.so.2[0xb7dccf2f]
/usr/lib/libfuse.so.2[0xb7dd2461]
/usr/lib/libfuse.so.2[0xb7dd2eb0]
/usr/lib/libfuse.so.2(fuse_session_process+0x26)[0xb7dd46d6]
/usr/lib/libfuse.so.2[0xb7dd0ad5]
/lib/tls/i686/cmov/libpthread.so.0[0xb7d9f4fb]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7d21e5e]
======= Memory map: ========
08048000-0804e000 r-xp 00000000 08:01 1340867    /usr/lib/gvfs/gvfs-fuse-daemon
0804e000-0804f000 rw-p 00005000 08:01 1340867    /usr/lib/gvfs/gvfs-fuse-daemon
0804f000-080b2000 rw-p 0804f000 00:00 0          [heap]
b5a00000-b5a21000 rw-p b5a00000 00:00 0 
b5a21000-b5b00000 ---p b5a21000 00:00 0 
b5b61000-b5b6b000 r-xp 00000000 08:01 588693     /lib/libgcc_s.so.1
b5b6b000-b5b6c000 rw-p 0000a000 08:01 588693     /lib/libgcc_s.so.1
b5b7d000-b5b7e000 ---p b5b7d000 00:00 0 
b5b7e000-b63a0000 rw-p b5b7e000 00:00 0 
b63a0000-b63a1000 ---p b63a0000 00:00 0 
b63a1000-b6ba1000 rw-p b63a1000 00:00 0 
b6ba1000-b6bc1000 r-xp 00000000 08:01 1831436    /usr/lib/gio/modules/libgvfsdbus.so
b6bc1000-b6bc2000 rw-p 0001f000 08:01 1831436    /usr/lib/gio/modules/libgvfsdbus.so
b6bc2000-b6bc3000 ---p b6bc2000 00:00 0 
b6bc3000-b73e5000 rw-p b6bc3000 00:00 0 
b73e5000-b73e6000 ---p b73e5000 00:00 0 
b73e6000-b7c0a000 rw-p b73e6000 00:00 0 
b7c0a000-b7c30000 r-xp 00000000 08:01 1768306    /usr/lib/libpcre.so.3.12.1
b7c30000-b7c31000 rw-p 00026000 08:01 1768306    /usr/lib/libpcre.so.3.12.1
b7c31000-b7c48000 r-xp 00000000 08:01 588797     /lib/libselinux.so.1
b7c48000-b7c4a000 rw-p 00016000 08:01 588797     /lib/libselinux.so.1
b7c4a000-b7c4b000 rw-p b7c4a000 00:00 0 
b7c4b000-b7d94000 r-xp 00000000 08:01 622421     /lib/tls/i686/cmov/libc-2.7.so
b7d94000-b7d95000 r--p 00149000 08:01 622421     /lib/tls/i686/cmov/libc-2.7.so
b7d95000-b7d97000 rw-p 0014a000 08:01 622421     /lib/tls/i686/cmov/libc-2.7.so
b7d97000-b7d9a000 rw-p b7d97000 00:00 0 
b7d9a000-b7dae000 r-xp 00000000 08:01 622435     /lib/tls/i686/cmov/libpthread-2.7.so
b7dae000-b7db0000 rw-p 00013000 08:01 622435     /lib/tls/i686/cmov/libpthread-2.7.so
b7db0000-b7db2000 rw-p b7db0000 00:00 0 
b7db2000-b7db4000 r-xp 00000000 08:01 622440     /lib/tls/i686/cmov/libutil-2.7.so
b7db4000-b7db6000 rw-p 00001000 08:01 622440     /lib/tls/i686/cmov/libutil-2.7.so
b7db6000-b7db8000 r-xp 00000000 08:01 622424     /lib/tls/i686/cmov/libdl-2.7.so
b7db8000-b7dba000 rw-p 00001000 08:01 622424     /lib/tls/i686/cmov/libdl-2.7.so
b7dba000-b7dc1000 r-xp 00000000 08:01 622437     /lib/tls/i686/cmov/librt-2.7.so
b7dc1000-b7dc3000 rw-p 00006000 08:01 622437     /lib/tls/i686/cmov/librt-2.7.so
b7dc3000-b7dc4000 rw-p b7dc3000 00:00 0 
b7dc4000-b7ddc000 r-xp 00000000 08:01 1768045    /usr/lib/libfuse.so.2.7.3
b7ddc000-b7ddd000 rw-p 00018000 08:01 1768045    /usr/lib/libfuse.so.2.7.3
b7ddd000-b7e11000 r-xp 00000000 08:01 1766910    /usr/lib/libdbus-1.so.3.4.0
b7e11000-b7e13000 rw-p 00033000 08:01 1766910    /usr/lib/libdbus-1.so.3.4.0
b7e13000-b7ec3000 r-xp 00000000 08:01 1767209    /usr/lib/libglib-2.0.so.0.1600.4
b7ec3000-b7ec4000 rw-p 000b0000 08:01 1767209    /usr/lib/libglib-2.0.so.0.1600.4
b7ec4000-b7ec7000 r-xp 00000000 08:01 1767237    /usr/lib/libgmodule-2.0.so.0.1600.4
b7ec7000-b7ec8000 rw-p 00002000 08:01 1767237    /usr/lib/libgmodule-2.0.so.0.1600.4
b7ec8000-b7f03000 r-xp 00000000 08:01 1767238    /usr/lib/libgobject-2.0.so.0.1600.4
b7f03000-b7f04000 rw-p 0003b000 08:01 1767238    /usr/lib/libgobject-2.0.so.0.1600.4
b7f04000-b7fAborted

Set enabled=1 in /etc/defaults/apport.

When it crashes have a look in /var/crash and there should be a file which has a name like the program that crashed.  If you can do that, that is even better than plain core file.

This last backtrace is different again.  It is crashing in vfs_open.

One way to get more reliable backtraces is to attach gdb to the fuse daemon after it starts up:

- Make sure the gvfs-fuse-daemon is running.
- Find the process name using "ps x | grep gvfs-fuse".
- Attach gdb to its PID (the leftmost number from ps) using "gdb /usr/lib/gvfs/gvfs-fuse-daemon <PID>".
- When gdb has finished loading symbols, issue the "continue" command on the (gdb) prompt.
- Make gvfs-fuse-daemon crash, and go back the the gdb window, which should say something about it having caught a signal of some sort.
- Issue "bt" and then "t a a bt" (because gdb can be wonky in the presence of threads), and copy all the output from those to a file.
- Attach the file to this bug.

Using valgrind, I've been able to get the following trace myself, when overwriting a file using gedit:

==26962== Thread 7:
==26962== Invalid read of size 1
==26962==    at 0x402576B: strcmp (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==26962==    by 0x4157A83: g_str_equal (gstring.c:77)
==26962==    by 0x41262C2: g_hash_table_remove_internal (ghash.c:137)
==26962==    by 0x804C7AF: vfs_rename (gvfsfusedaemon.c:318)
==26962==    by 0x41ED072: fuse_fs_rename (fuse.c:778)
==26962==    by 0x41F45A0: fuse_lib_rename (fuse.c:1725)
==26962==    by 0x41F6DE6: do_rename (fuse_lowlevel.c:569)
==26962==    by 0x41F68B8: fuse_ll_process (fuse_lowlevel.c:1182)
==26962==    by 0x41F9415: fuse_session_process (fuse_session.c:90)
==26962==    by 0x41F53A8: fuse_do_work (fuse_loop_mt.c:100)
==26962==    by 0x421B174: start_thread (in /lib/libpthread-2.8.so)
==26962==    by 0x42FADCD: clone (in /lib/libc-2.8.so)
==26962==  Address 0x4572830 is 0 bytes inside a block of size 19 free'd
==26962==    at 0x4023B7A: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==26962==    by 0x413B425: g_free (gmem.c:190)
==26962==    by 0x804C78D: vfs_rename (gvfsfusedaemon.c:316)
==26962==    by 0x41ED072: fuse_fs_rename (fuse.c:778)
==26962==    by 0x41F45A0: fuse_lib_rename (fuse.c:1725)
==26962==    by 0x41F6DE6: do_rename (fuse_lowlevel.c:569)
==26962==    by 0x41F68B8: fuse_ll_process (fuse_lowlevel.c:1182)
==26962==    by 0x41F9415: fuse_session_process (fuse_session.c:90)
==26962==    by 0x41F53A8: fuse_do_work (fuse_loop_mt.c:100)
==26962==    by 0x421B174: start_thread (in /lib/libpthread-2.8.so)
==26962==    by 0x42FADCD: clone (in /lib/libc-2.8.so)
==26962== 
==26962== Invalid read of size 1
==26962==    at 0x402578A: strcmp (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==26962==    by 0x4157A83: g_str_equal (gstring.c:77)
==26962==    by 0x41262C2: g_hash_table_remove_internal (ghash.c:137)
==26962==    by 0x804C7AF: vfs_rename (gvfsfusedaemon.c:318)
==26962==    by 0x41ED072: fuse_fs_rename (fuse.c:778)
==26962==    by 0x41F45A0: fuse_lib_rename (fuse.c:1725)
==26962==    by 0x41F6DE6: do_rename (fuse_lowlevel.c:569)
==26962==    by 0x41F68B8: fuse_ll_process (fuse_lowlevel.c:1182)
==26962==    by 0x41F9415: fuse_session_process (fuse_session.c:90)
==26962==    by 0x41F53A8: fuse_do_work (fuse_loop_mt.c:100)
==26962==    by 0x421B174: start_thread (in /lib/libpthread-2.8.so)
==26962==    by 0x42FADCD: clone (in /lib/libc-2.8.so)
==26962==  Address 0x4572831 is 1 bytes inside a block of size 19 free'd
==26962==    at 0x4023B7A: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==26962==    by 0x413B425: g_free (gmem.c:190)
==26962==    by 0x804C78D: vfs_rename (gvfsfusedaemon.c:316)
==26962==    by 0x41ED072: fuse_fs_rename (fuse.c:778)
==26962==    by 0x41F45A0: fuse_lib_rename (fuse.c:1725)
==26962==    by 0x41F6DE6: do_rename (fuse_lowlevel.c:569)
==26962==    by 0x41F68B8: fuse_ll_process (fuse_lowlevel.c:1182)
==26962==    by 0x41F9415: fuse_session_process (fuse_session.c:90)
==26962==    by 0x41F53A8: fuse_do_work (fuse_loop_mt.c:100)
==26962==    by 0x421B174: start_thread (in /lib/libpthread-2.8.so)
==26962==    by 0x42FADCD: clone (in /lib/libc-2.8.so)

It looks fixable. I'm looking into it.

Created attachment 114694 [details] [review]
gvfs-fuse-rename-early-free.patch

This patch might fix the problem; the path should be freed after removing its struct from the hash table, since it's being used as the key.

Hans: 

Yep that's a winner!

I reproduced the behaviour using gedit on the current package (gvfs-fuse segfaulted after 2 saves in gedit) then built new gvfs-fuse packages using your one-line patch.

After this, I was able to keep pressing Space then CTRL-S for 10 seconds (i.e. about 3 saves per second) without any problems. 

The file size of the text file was even updated live in the Nautilus window for /home/gdh/.gvfs/share on server/test.txt

Thank you! :) 

Sebastien: Does this affect your initial problem?

I've committed the last patch to trunk and 2-22.

Hans: Sebastian is an Ubuntu bug marshal - I'm the OP - Sebastian forwarded the bug from Ubuntu's Launchpad:

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/235326

Great. I'll close the bug then. Please reopen if you find more crashers.

I found the bug causing the initial trace too. Appending a separate patch for that. It's already been applied to trunk and 2-22.

Created attachment 114799 [details] [review]
gvfs-fuse-lock-on-open.patch

*** Bug 540084 has been marked as a duplicate of this bug. ***