May I ask you for a backtrace of the backend process (gvfsd-smb)? It looks like bug 675181

never done a backtrace, can you point me in the right direction?

found how to do a backtrace.
But if I attach gdb to the running gvfsd-smb and continue, 
gdb does not react on hitting ctrl-c, so I cant backtrace

Right, sorry, should've posted a link here: http://fedoraproject.org/wiki/StackTraces (it's generally applicable to other distros as well)

(In reply to comment #3)
> But if I attach gdb to the running gvfsd-smb and continue, 
> gdb does not react on hitting ctrl-c, so I cant backtrace

It should, seems like a problem with gdb then. I think there's also a call to grab backtrace right away, maybe with little gdb scripting.

Created attachment 241254 [details]
backtrace gvfsd-smb hangs

thanks, attached the backtrace,
do I need to install debug symbols or debug info packages?

I am having random freezes when playing (vlc, totem) media files, but not all the time... Is this bug happening always or random like with me?

it is random, not all the time, but when it starts, it gets worse.
I can play a video like 5-10 times and then it starts, so I get this very fast.

xkill works when kill -9 doesn't.

(In reply to comment #9)
> xkill works when kill -9 doesn't.

Oh god... 

(In reply to comment #6)
> thanks, attached the backtrace,
> do I need to install debug symbols or debug info packages?

Yes please, they're essential to have a trace with human readable symbols.

@Thomas:
thought the same about xkill ;-)
I'll try to get you the backtrace with debug info on monday,
its my linux machine at work.

It get's worse for me also... When totem fails once, it keeps on failing until I reboot (although there might be a more efficient way to get it working again).

Created attachment 241547 [details]
backtrace gvfsd-smb hangs 2

Created attachment 242114 [details]
 backtrace gvfsd-smb hangs 3

Looks like I'm experiencing same issue. I'm using xubuntu raring beta.

The problem occurs when I try to directory containing many photos from windows XP machine. That is: directory with some subdirectories containing jpg files (several megs in size) and some small metadata files. It starts copying fine but hangs at random file.

Attaching backtrace - looks very similar to one attached before.

I would be happy to help debugging this issue.

There is a quite popular bug open on Launchpad about this issue. It seems that it is a regression introduced in the upgrade from 1.13 to 1.14, and still with us. Debian Wheezy is not affected and everything after that seems that is.  

Please see https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923

Given the potential effects of this bug (I can workaround with directly mounting with cifs or smbmount, but that's not a normal user action, or using NFS in a linux-only setup), and the widespread use of gvfs-smb mounts, I advocate for raising the importance of the bug. 

Thanks for the attention, and as ever a thank to all the developers,
Have a nice day,
Romano

(In reply to comment #15)
> There is a quite popular bug open on Launchpad about this issue. It seems that
> it is a regression introduced in the upgrade from 1.13 to 1.14, and still with
> us. Debian Wheezy is not affected and everything after that seems that is.  

Sorry, from 1.12 to 1.14.

Speaking as yet another person suffering from this bug, I think it's safe to mark this as confirmed.  It crops up on my Xubuntu Quantal amd64 system (gvfs-backends 1.14.0) quite often when I copy gigabyte-size files to my NAS, freezing Thunar until I kill gvfsd-smb.

Ubuntu Raring 64, gvfs 1.16.1, Nautilus 3.6.3

Transferred 26678 files, 48,3 GB without issues.
gvfsd-smb memory usage grew from about 3 to 15 Mb, and nautilus' from 10 to about 50Mb during the copy.
At the end of the copy, I noticed that neither process had released any memory.

So I started a second copy.
gvfd-smb grew to 32 Mb and nautilus to 74. Again, no memory release. I noticed that both processes memory usage grows much more quickly when transferring many small files, than when dealing with few but large ones.

Third time, gvfsd-smb up to 46 and nautilus up to 99

So I kept trying until I finally had the copy hang.
gvfsd-smb memory usage had grown to about 130Mb and nautilus' to about 250 Mb.

Is this behaviour normal?

For the record, these hangs do not occur when accessing the same file server via mount.cifs.

Hi, 
I think this is a very serious regression --- can I humbly suggest that the developers confirm and raise the priority of this bug? It's a quite unpredictable hang and there is even a case of data loss (see the launchpad thread).

(In reply to comment #18)
> Ubuntu Raring 64, gvfs 1.16.1, Nautilus 3.6.3

Okay, gvfs-1.16.1 got the gvfschannel fixes I was referring to.

> So I kept trying until I finally had the copy hang.

Can you please grab a backtrace of the backend process (gvfsd-smb) and nautilus at the moment of hang?

> gvfsd-smb memory usage had grown to about 130Mb and nautilus' to about 250 Mb.
> 
> Is this behaviour normal?

You've probably found a memory leak, if you're certain with that, please open a separate bugreport preferably with valgring log (see https://live.gnome.org/Valgrind for usage).

As there are multiple reporters, I would like to know the way the files are accessed. The original report talks about accessing through the fuse daemon while e.g. the reporter in comment 18 is talking about Nautilus, which is a native GIO client. We may be dealing with two issues here actually.

(In reply to comment #20)
> It's a quite unpredictable hang and there is even a case of data loss (see the launchpad thread).

Nobody is going to read that 155 comments, can you post an excerpt here talking about data loss?

@Thomas:

In Mint 14 Nadia Cinnamon 64 I use nemo to connect to the windows share.
In Ubuntu 13.04 Raring 64 I use nautilus to connect to the windows share.

Nautilus and Nemo in Menue: File => Connect to server:
smb://xxx.xxx.xxx.xxx/public

@Thomas:

In Mint 14 Nadia Cinnamon 64 I use nemo to connect to the windows share.
In Ubuntu 13.04 Raring 64 I use nautilus to connect to the windows share.

Nautilus and Nemo in Menue: File => Connect to server:
smb://xxx.xxx.xxx.xxx/public

@Tomas: you're right, sorry. The data loss report is 

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923/comments/150

although at first glance it seems more a bug of the frontend for not checking the success of the operation before removing the source file. 

I triggered the bug using nautilus (ubuntu 12.10, gnome shell desktop with the nautilus from the distribution --- it says 3.4.2. When I connect to a SMB-share, it spawns 

romano   13269  0.0  0.1  59140  6300 ?        SLl  12:43   0:00 /usr/lib/gvfs/gvfsd-smb --spawner :1.4 /org/gtk/gvfs/exec_spaw/3

I don't understand very well your comment about GIO --- I suspect that Nautilus is using gvfs-fuse and gvfs-smb nowadays.

(In reply to comment #25)
> I don't understand very well your comment about GIO --- I suspect that Nautilus
> is using gvfs-fuse and gvfs-smb nowadays.

The FUSE daemon is provided only as a fallback to non-Gnome applications (simply speaking), Natilus and his clones have been native GIO clients from beginning. 

I.e. the vlc from the first post is an example of application that doesn't support GIO (unless ported to it) and needs to go through the compatibility (FUSE) POSIX layer.

(In reply to comment #25)
> @Tomas: you're right, sorry. The data loss report is 
> 
> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923/comments/150
> 
> although at first glance it seems more a bug of the frontend for not checking
> the success of the operation before removing the source file. 

Thanks, though the post contains very little technical information and we can't even guess what was the situation about. And the last paragraph is simply amusing.

There's a possibility that the error reporting is not working as expected but we need to know more information in order to fix that. Basically error reporting is developer's biggest concern yet due to multiple stacks involved (e.g. libsmbclient -> gvfsd-smb -> gvfsd -> libgvfsdbus.so -> GIO -> gvfsd-fuse -> POSIX application) the possibility of mistake is large by nature.

(In reply to comment #26)
> 
> The FUSE daemon is provided only as a fallback to non-Gnome applications
> (simply speaking), Natilus and his clones have been native GIO clients from
> beginning. 
> 
OK --- clearer now. I had the bug simply copying files though. I was copying photos with nautilus while viewing them with gthumb. Maybe could be a race between native and non-native applications? 

If you can think of a test case I can try to repeat the hang --- I have since switched to using rsync to copy stuff but I can try ;-)

It also affects me.
When I try to copy files from QNAP NAS share, samba randomly hangs without any notice.
Using a clean install of Ubuntu 12.10 and Ubuntu 13.04 (64 bit).
This problem was not present in Ubuntu 12.04.

Okay, this explains some issues I am having with Ubuntu 13.04, raring.  Actually, it even happens when transferring files to an SD card, with and fstab entry for that device.  No other file manager experiences this hang.

I have 2 machines running 13.10 Saucy amd64 mixed Ubuntu/Xubuntu/Kubuntu/etc

Problem still exist with Nautilus, Nemo, PCManFM

gvfs 1.17.2-0ubuntu3

Dolphin works fine.

I should add:

nautilus 1:3.8.2-0ubuntu1

Just got bit by this bug. I have two laptops running Ubuntu 13.04. The faster one with an Intel Core I5 is running x86, and the slower one is running amd64. (I prefer x86, but the slower laptop had a different bug that prevented me from using x86.) The fast laptop doesn't have any Nautilus / Samba / GVFS problems, but the slow laptop is completely broken for file transfers. I don't know if this has to do with the speed or if 32bit vs 64bit makes the difference.

Is this bug exclusive to Ubuntu?

(In reply to comment #33)
> Is this bug exclusive to Ubuntu?

No, I am having this issue on two arch machines...

Have this bug on Fedora, at least the part where nautilus hangs when transfering files from remote samba shares. Seems more stable when disabling thumbnails in nautilus settings.

I think I have pinpointed the problem and come up with a fix (patch attached).
FWIW, I could hit this issue by running:
gvfs-mount 'smb://ip/share' && cp -rv /run/user/1000/gvfs/smb-share\:server\=ip\,share\=share/path /tmp

commit 75ebd95d899f52e1d14b3492b38906bad91b10b8
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date:   Sat Sep 21 22:22:27 2013 +0200

    daemon: Emit signal before returning dbus value
    
    In gvfsjobopenforread.c, the dbus method returns a value in create_reply
    which eventually results in a GVfsJobRead job to be sent to the backend.
    This could happen before the "new-source" signal is emitted.  If this
    happens, the job is not queued because the "new_job" signal would not
    have been connected to a job source yet.  The read then hangs because
    the GVfsJobRead is lost.
    
    This is hit often when performing large smb transfers (see
    https://bugzilla.gnome.org/show_bug.cgi?id=697782 and
    https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923).
    It can be reproduced by putting a small sleep before the
    g_signal_emit_by_name call.
    
    Fix this by emitting the "new-source" signal *before* the dbus method
    value is returned.  This ensures that the "new_job" signal is set up
    before any further jobs are sent.

Created attachment 255499 [details] [review]
Patch to fix the problem

Created attachment 255500 [details] [review]
Patch to fix the problem (v2)

Updated patch.

Sounds promising.  Is there a corresponding fix to be made for writes?  It seems to me that I've run into this problem when copying files *to* my samba server.

Yes, I just managed to reproduce that too.  I have attached an updated patch which fixes it.

Created attachment 255536 [details] [review]
Patch to fix the problem (v3)

Add the same fix for gvfsjobopenforwrite.c.

@Ross

thanks for your patch. I want to test it on my machine, but I'm not very familiar with the build system.

I downloaded the sourcecode of gvfs by:
sudo apt-get build-dep gvfs
sudo apt-get source gvfs

Now I have a folder called "gvfs-1.16.1" in my home. I can add your patch here.
But how do I build and install the patched version on my machine?

@Ross

thanks for your patch. I want to test it on my machine, but I'm not very familiar with the build system.

I downloaded the sourcecode of gvfs by:
sudo apt-get build-dep gvfs
sudo apt-get source gvfs

Now I have a folder called "gvfs-1.16.1" in my home. I can add your patch here.
But how do I build and install the patched version on my machine?

I have it in a PPA here: https://launchpad.net/~rosslagerwall/+archive/bugfixes

Or else try this:
cd gvfs-1.16.1
patch -p1 < 0001-daemon-Emit-signal-before-returning-dbus-value.patch
dpkg-buildpackage -us -uc
sudo dpkg -i ../*deb

@Ross

installed your ppa.
Checked installation, your ppa seems to be installed:


dpkg -l | grep gvfs


ii  gvfs:amd64                                  1.16.1-0ubuntu2~rc2                        amd64        userspace virtual filesystem - GIO module
ii  gvfs-backends                               1.16.1-0ubuntu2~rc2                        amd64        userspace virtual filesystem - backends
ii  gvfs-bin                                    1.16.1-0ubuntu2~rc2                        amd64        userspace virtual filesystem - binaries
ii  gvfs-common                                 1.16.1-0ubuntu2~rc2                        all          userspace virtual filesystem - common data files
ii  gvfs-daemons                                1.16.1-0ubuntu2~rc2                        amd64        userspace virtual filesystem - servers
ii  gvfs-fuse                                   1.16.1-0ubuntu2~rc2                        amd64        userspace virtual filesystem - fuse server
ii  gvfs-libs:amd64                             1.16.1-0ubuntu2~rc2                        amd64        userspace virtual filesystem - private libraries


rebooted, and did the steps in my post #1.
Video player still hangs. I get the same behaviour as before.

Am I doing something wrong? Can I give you some more input?
I can produce this effect very easily by running Mint 15 in a virtual box.
Seems to have something to do with speed of computers?

(In reply to comment #45)
> @Ross
> 
> rebooted, and did the steps in my post #1.
> Video player still hangs. I get the same behaviour as before.
> 
> Am I doing something wrong? Can I give you some more input?
> I can produce this effect very easily by running Mint 15 in a virtual box.
> Seems to have something to do with speed of computers?

Well it's possible that there's more than one problem :-(
The patch I posted certainly fixed performing a large copy from a windows share for me.


I guess for debugging purposes, it would be useful to run something like:
pkill gvfsd
GVFS_DEBUG=all GVFS_SMB_DEBUG=6 /usr/lib/gvfs/gvfsd &> log.txt

Then do the thing that fails (playing a video), press Ctrl-C and upload log.txt somewhere...

thanks, I can get you the log tomorrow

I have to revise my comment #45:

The patch from Ross is working for copying large files.
So this is definitely an improvement to gvfs.

I still sometimes have problems playing videos, but I don't know, 
how far this is related to gvfs. 

Thanks!

Review of attachment 255536 [details] [review]:

Great catch!

Pushed this to master as bdc3babbe21e5fed06876db4d56d1b13915fe1cb.
I guess we need a new release with this...

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

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