After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 376388 - Copying from windows share to webdav directory can crash nautilus
Copying from windows share to webdav directory can crash nautilus
Status: RESOLVED INCOMPLETE
Product: gnome-vfs
Classification: Deprecated
Component: Module: http
2.14.x
Other other
: High critical
: ---
Assigned To: Christian Kellner
gnome-vfs maintainers
Depends on:
Blocks:
 
 
Reported: 2006-11-17 17:58 UTC by chris
Modified: 2008-11-15 17:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description chris 2006-11-17 17:56:53 UTC
Distribution: Fedora Core release 5 (Bordeaux)
Package: nautilus
Severity: Normal
Version: GNOME2.14.3 2.14.3
Gnome-Distributor: Red Hat, Inc
Synopsis: Copying from windows share to webdav directory can crash nautilus
Bugzilla-Product: nautilus
Bugzilla-Component: general
Bugzilla-Version: 2.14.3
BugBuddy-GnomeVersion: 2.0 (2.14.1)
Description:
Description of the crash:

I'm running Fedora Core 5 - up-to-date as of 17th Nov 2006. When trying
to copy from a windows share to a webdav directory, nautilus sometimes
crashes, and sometimes the copy dialog just disappears and the copy
operation ceases. Seems to happen with large files, i.e. CD ISOs. Also
the copy operation mysteriously ceased when copying a folder with many
sub-directories, I think 5 directories deep.

Steps to reproduce the crash:
1. Go to the windows share and highlight a bunch of directories, in this
case it was two or three but it has happened before with just one
directory containing several sub-directories.
2. Right-click and click Copy.
3. Navigate to the WebDAV directory, right click the directory and click
"Paste into folder"
4. The operation copied some of the files but crashed nautilus some way
through the operation.

Expected Results:

Would expect the copying to just continue, or some kind of error message
if there's a reason for the copy being unable to proceed.

How often does this happen?

The operation always fails on certain directories. Sometimes nautilus
crashes and I get the "Report a bug" dialog. Sometimes the Copy dialog
just disappears and no more files are copied. I can restart the copy but
it always seems to fail at the same place.

Additional Information:

Apologies if my bug report is no good, it's my first attempt but I
thought some information is better than none. :)


Debugging Information:

Backtrace was generated from '/usr/bin/nautilus'

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
`shared object read from target memory' has disappeared; keeping its
symbols.
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208763664 (LWP 9205)]
[New Thread -1221842016 (LWP 12440)]
[New Thread -1211085920 (LWP 9208)]
(no debugging symbols found)
0x00f50402 in __kernel_vsyscall ()

Thread 2 (Thread -1221842016 (LWP 12440))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/libpthread.so.0
  • #2 gnome_gtk_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #3 <signal handler called>
  • #4 __kernel_vsyscall
  • #5 raise
    from /lib/libc.so.6
  • #6 abort
    from /lib/libc.so.6
  • #7 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #8 g_log
    from /usr/lib/libglib-2.0.so.0
  • #9 g_realloc
    from /usr/lib/libglib-2.0.so.0
  • #10 g_ptr_array_new
    from /usr/lib/libglib-2.0.so.0
  • #11 g_array_append_vals
    from /usr/lib/libglib-2.0.so.0
  • #12 g_byte_array_append
    from /usr/lib/libglib-2.0.so.0
  • #13 vfs_module_shutdown
    from /usr/lib/gnome-vfs-2.0/modules/libhttp.so
  • #14 gnome_vfs_find_directory
    from /usr/lib/libgnomevfs-2.so.0
  • #15 gnome_vfs_write_cancellable
    from /usr/lib/libgnomevfs-2.so.0
  • #16 gnome_vfs_write
    from /usr/lib/libgnomevfs-2.so.0
  • #17 gnome_vfs_xfer_delete_list
    from /usr/lib/libgnomevfs-2.so.0
  • #18 gnome_vfs_xfer_delete_list
    from /usr/lib/libgnomevfs-2.so.0
  • #19 gnome_vfs_xfer_delete_list
    from /usr/lib/libgnomevfs-2.so.0
  • #20 gnome_vfs_xfer_delete_list
    from /usr/lib/libgnomevfs-2.so.0
  • #21 gnome_vfs_xfer_uri
    from /usr/lib/libgnomevfs-2.so.0
  • #22 gnome_vfs_job_get_count
    from /usr/lib/libgnomevfs-2.so.0
  • #23 gnome_vfs_async_set_job_limit
    from /usr/lib/libgnomevfs-2.so.0
  • #24 g_thread_pool_push
    from /usr/lib/libglib-2.0.so.0
  • #25 g_thread_create_full
    from /usr/lib/libglib-2.0.so.0
  • #26 start_thread
    from /lib/libpthread.so.0
  • #27 clone
    from /lib/libc.so.6




------- Bug created by bug-buddy at 2006-11-17 17:58 -------


Unknown version 2.14.3 in product nautilus.  Setting version to "2.14.x".

Comment 1 Martin Wehner 2006-12-19 13:19:41 UTC
Reassigning -> gnome-vfs
Comment 2 palfrey 2007-04-08 13:39:29 UTC
Thanks for taking the time to report this bug.
Unfortunately, that stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 3 Chris Mocock 2007-04-10 10:56:28 UTC
(In reply to comment #2)
> Can you get us a stack trace with debugging symbols? Please see
> http://live.gnome.org/GettingTraces for more information on how to do so.
> Thanks in advance!

I'm afraid that since I made the initial bug report, I've upgraded to FC6. The good news is that the behaviour now seems a lot more reliable. I've done some pretty extensive testing today, repeating the operations I was performing before, and I cannot get it to crash again. 

However, there are two related issues I've noticed when doing the same operations, neither of which crash nautilus so I have no backtrace despite installing the debug version of gnome-vfs2. I'll list the issues here, please let me know if I should submit separate bug reports for either or both of these:

1. When copying a large file (in this case 580MB), the operation seems to be proceeding, but when it gets to 100%, the copy dialog remains until eventually a message appears saying ' Error "Timeout reached" when copying "smb://filename" '.
Nautilus reports 0 bytes for the destination file. I checked the file on the webdav server using ls -l and it is indeed 0 bytes.

2. When copying from a smb share to a webdav folder, files containing ampersands fail to copy to the webdav folder. I copied a complex tree of files which had 5913 files on the smb share. When copied across to the webdav, the folder properties reported 4017 files and said "(some contents unreadable)". Maybe this is reasonable/expected behaviour but thought I'd mention it.

Comment 4 André Klapper 2008-11-15 17:15:31 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!