When coping many small files from remote machine gvfsd-smb eventually dies with SIGSEGV:
#0  0x08056b82 in command_read_cb (source_object=0xb5c09340 [GUnixInputStream], res=0x819eaa8, user_data=0xb5c007b0) at gvfschannel.c:498
#1  0xb7053f9f in async_ready_callback_wrapper (source_object=0xb5c09340 [GUnixInputStream], res=0x819eaa8, user_data=0xb5c007b0) at /build/buildd/glib2.0-2.26.1/gio/ginputstream.c:470
#2  0xb706457f in g_simple_async_result_complete (simple=0x819eaa8 [GSimpleAsyncResult]) at /build/buildd/glib2.0-2.26.1/gio/gsimpleasyncresult.c:692
#3  0xb70877d7 in read_async_cb (data=0xb5c03b98, condition=17, fd=48) at /build/buildd/glib2.0-2.26.1/gio/gunixinputstream.c:471
#4  0xb702a70b in fd_source_dispatch (source=0xb5c1a0c0, callback=0xb70876c0 <read_async_cb>, user_data=0xb5c03b98) at /build/buildd/glib2.0-2.26.1/gio/gasynchelper.c:81
#5  0xb6ec0855 in g_main_dispatch (context=0x80d2088) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2149
#6  g_main_context_dispatch (context=0x80d2088) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2702
#7  0xb6ec4668 in g_main_context_iterate (context=0x80d2088, block=<value optimised out>, dispatch=1, self=0x80c6b30) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2780
#8  0xb6ec4ba7 in g_main_loop_run (loop=0x80d27d8) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2988
#9  0x08051faa in daemon_main (argc=4, argv=0xbfb25b84, max_job_threads=1, default_type=0x80659ab "smb-share", mountable_name=0x0, first_type_name=0x80659ab "smb-share") at daemon-main.c:294
#10 0x080522b6 in main (argc=4, argv=0xbfb25b84) at daemon-main-generic.c:39

Problem is very well reproducible on Ubuntu 10.10. There is a bug report on launchpad describing same issue: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/682850 (not mine).

I was able to check that in gvfschannel.c:command_read_cb value of reader->channel is not zero at 'if (reader->channel == NULL)' but later is zero at 'reader->channel->priv->request_reader = NULL;' resulting in NULL pointer dereference.

With gdb config:
----------------------------------------
break gvfschannel.c:543
commands
  p reader
  bt
  cont
end

break gvfschannel.c:125
commands
  p channel->priv->request_reader
  bt
  cont
end

break gvfschannel.c:286
commands
  p reader
  bt
  cont
end

break gvfschannel.c:487
commands
  p reader
  bt
  cont
end

break gvfschannel.c:498 if reader->channel==0
commands
  p reader
end
----------------------------------------

I get following output:
----------------------------------------
[Switching to Thread 0xb5bffb70 (LWP 20101)]

Breakpoint 2, g_vfs_channel_finalize (object=0x9a47508 [GVfsReadChannel]) at gvfschannel.c:125
125	  if (channel->priv->current_job)
$395 = (RequestReader *) 0x9a555e0
#0  g_vfs_channel_finalize (object=0x9a47508 [GVfsReadChannel]) at gvfschannel.c:125
#1  0x08065b24 in g_vfs_read_channel_finalize (object=0x9a47508 [GVfsReadChannel]) at gvfsreadchannel.c:70
#2  0xb6fa2994 in g_object_unref (_object=0x9a47508) at /build/buildd/glib2.0-2.26.1/gobject/gobject.c:2712
#3  0x0805d213 in g_vfs_job_close_read_finalize (object=0x9994c40 [GVfsJobCloseRead]) at gvfsjobcloseread.c:48
#4  0xb6fa2994 in g_object_unref (_object=0x9994c40) at /build/buildd/glib2.0-2.26.1/gobject/gobject.c:2712
#5  0x08058a03 in g_vfs_job_run (job=0x9994c40 [GVfsJobCloseRead]) at gvfsjob.c:200
#6  0x08052a54 in job_handler_callback (data=0x9994c40, user_data=0x9989520) at gvfsdaemon.c:144
#7  0xb6eb73d4 in g_thread_pool_thread_proxy (data=0x99938a8) at /build/buildd/glib2.0-2.26.1/glib/gthreadpool.c:319
#8  0xb6eb548f in g_thread_create_proxy (data=0x9998ae8) at /build/buildd/glib2.0-2.26.1/glib/gthread.c:1897
#9  0xb6f3dcc9 in start_thread (arg=0xb5bffb70) at pthread_create.c:304
#10 0xb6dc069e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
[Switching to Thread 0xb68f7730 (LWP 20079)]

Breakpoint 4, command_read_cb (source_object=0x9a0d4a0 [GUnixInputStream], res=0x9994d58, user_data=0x9a555e0) at gvfschannel.c:487
487	  if (reader->channel == NULL)
$396 = (RequestReader *) 0x9a555e0
#0  command_read_cb (source_object=0x9a0d4a0 [GUnixInputStream], res=0x9994d58, user_data=0x9a555e0) at gvfschannel.c:487
#1  0xb701df9f in async_ready_callback_wrapper (source_object=0x9a0d4a0 [GUnixInputStream], res=0x9994d58, user_data=0x9a555e0) at /build/buildd/glib2.0-2.26.1/gio/ginputstream.c:470
#2  0xb702e57f in g_simple_async_result_complete (simple=0x9994d58 [GSimpleAsyncResult]) at /build/buildd/glib2.0-2.26.1/gio/gsimpleasyncresult.c:692
#3  0xb70517d7 in read_async_cb (data=0x9a50e98, condition=17, fd=31) at /build/buildd/glib2.0-2.26.1/gio/gunixinputstream.c:471
#4  0xb6ff470b in fd_source_dispatch (source=0x9a3ecd8, callback=0xb70516c0 <read_async_cb>, user_data=0x9a50e98) at /build/buildd/glib2.0-2.26.1/gio/gasynchelper.c:81
#5  0xb6e8a855 in g_main_dispatch (context=0x9993088) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2149
#6  g_main_context_dispatch (context=0x9993088) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2702
#7  0xb6e8e668 in g_main_context_iterate (context=0x9993088, block=<value optimised out>, dispatch=1, self=0x9987b30) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2780
#8  0xb6e8eba7 in g_main_loop_run (loop=0x99937d8) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2988
#9  0x0805275b in daemon_main (argc=4, argv=0xbfe6cfa4, max_job_threads=1, default_type=0x8068342 "smb-share", mountable_name=0x0, first_type_name=0x8068342 "smb-share") at daemon-main.c:294
#10 0x080527ba in main (argc=4, argv=0xbfe6cfa4) at daemon-main-generic.c:39

Breakpoint 5, command_read_cb (source_object=0x9a0d4a0 [GUnixInputStream], res=0x9994d58, user_data=0x9a555e0) at gvfschannel.c:498
498	      reader->channel->priv->request_reader = NULL;
$397 = (RequestReader *) 0x9a555e0
----------------------------------------

This shows that in one thread channel is being unrefed in 'g_vfs_job_close_read_finalize' while in another thread it is still being used by 'command_read_cb. And although breakpoint 2 happens before breakpoint 4 we still get to breakpoint 5 and NULL pointer dereference. I'd guess this is because two core system or the way gdb handles several threads.

I think the problem occurs because RequestReader holds reference to channel but never calls g_object_ref/g_object_unref on it.

I'll attach patch which fixes problem for me. It can be applied to 1.6.4 as well as current git.
