Nautilus segfaults while transferring files via SFTP

[Julien Olivier]

Every time I try to transfer a large file (or several small files) via Nautilus/SFTP, it ends up failing after a minute or so (connection closed).

For example, I tried the same transfer twice, and got the following log:

[505587.786931] gvfsd-sftp[23481]: segfault at 1 ip 0000000000000001 sp 00007ffe3e316a58 error 14 in gvfsd-sftp[559f94955000+6000]
[505587.786958] Code: Bad RIP value.
[505856.692209] gvfsd-sftp[23767]: segfault at 559d0000000a ip 00007fa35323bc04 sp 00007ffc3f4d7d90 error 4 in libc-2.30.so[7fa3531c8000+178000]
[505856.692233] Code: c9 0f 11 4b 20 48 89 ee 66 48 0f 6e c0 48 83 ce 01 0f 16 44 24 08 48 89 73 08 0f 11 43 10 49 89 2c 24 48 85 d2 74 8f 48 89 d3 <48> 8b 43 08 89 c2 c1 ea 04 83 ea 02 49 8d 54 d7 10 49 39 d5 0f 85

If I try the same transfer using Filezilla, it completes flawlessly. Also, before Ubuntu 19.10 / Nautilus 3.34, I didn't have any problems with the same server either.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: nautilus 1:3.34.1-1ubuntu1
ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
Uname: Linux 5.3.0-23-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue Nov 26 07:48:38 2019
GsettingsChanges:
 b'org.gnome.nautilus.icon-view' b'default-zoom-level' b"'large'"
 b'org.gnome.nautilus.window-state' b'sidebar-width' b'209'
 b'org.gnome.nautilus.window-state' b'initial-size' b'(890, 538)'
InstallationDate: Installed on 2018-05-14 (560 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
UpgradeStatus: Upgraded to eoan on 2019-10-18 (38 days ago)
usr_lib_nautilus:

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

[Julien Olivier (julo)]

I just attached the .crash updated by apport-retrace.

[Sebastien Bacher (seb128)]

Can you submit it using 'ubuntu-bug ...crash'? adding it to a comment like this isn't practical

[Julien Olivier (julo)]

I've just run "ubuntu-bug /var/crash/_usr_lib_gvfs_gvfsd-sftp.1000.crash", then clicked on "send". Now, nothing happens. Is it normal?

[Sebastien Bacher (seb128)]

It didn't give you a report ID? Can you look at https://errors.ubuntu.com/user/ID where ID is the content of file /var/lib/whoopsie/whoopsie-id on the machine and share the url?

[Julien Olivier (julo)]

https://errors.ubuntu.com/user/48706022a1eb9a1460914442b5800ac75480d612cb57c8df5cd3cf920eb42797803624177a2fa97cc4c46fd865fa40a4b32225eb30790d2d7cde0622a541b5db

I can see some of my error reports, but the last ones (sent via ubuntu-bug /var/crash/_usr_lib_gvfs_gvfsd-sftp.1000.crash) don't appear.

[Julien Olivier (julo)]

Also note that I have an empty /var/crash/_usr_lib_gvfs_gvfsd-sftp.1000.upload, in case it matters.

[Julien Olivier (julo)]

So, what now? Do you need me to do try anything else? Or send you logs using another method?

[Sebastien Bacher (seb128)]

The error from your reports looks like bug #1854812 with this stacktrace

'#0 tcache_get (tc_idx=<optimized out>) at malloc.c:2937
        e = 0x7f3000000002
#1 __GI___libc_malloc (bytes=32) at malloc.c:3051
        ar_ptr = <optimized out>
        victim = <optimized out>
        hook = <optimized out>
        tbytes = <optimized out>
        tc_idx = <optimized out>
        __PRETTY_FUNCTION__ = "__libc_malloc"
#2 0x00007f30a77944e9 in g_malloc () from /srv/daisy.ubuntu.com/production/cache/Ubuntu 19.10/cache-8mCgcG/sandbox/Ubuntu 19.10/amd64/report-sandbox/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3 0x00007f30a778c509 in g_source_set_callback () from /srv/daisy.ubuntu.com/production/cache/Ubuntu 19.10/cache-8mCgcG/sandbox/Ubuntu 19.10/amd64/report-sandbox/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4 0x00007f30a7974b24 in g_task_attach_source (task=0x7f309801b3c0, source=0x5643e2f49800, callback=0x7f30a7974060 <complete_in_idle_cb>) at ../../../gio/gtask.c:1616
        __FUNCTION__ = "g_task_attach_source"
#5 0x00007f30a7974bc4 in g_task_return (task=0x7f309801b3c0, type=<optimized out>) at ../../../gio/gtask.c:1291
        source = 0x5643e2f49800
#6 0x00007f30a793e0df in read_async_pollable (stream=0x7f3090001560, task=task@entry=0x7f309801b3c0) at ../../../gio/ginputstream.c:1365
        op = <optimized out>
        error = 0x0
        nread = 2084
#7 0x00007f30a794002d in g_input_stream_real_read_async (stream=0x7f3090001560, buffer=0x5643e2f49cc0, count=32777, io_priority=0, cancellable=<optimized out>, callback=0x7f30a793fce0 <async_ready_callback_wrapper>, user_data=0x5643e2ec6148) at ../../../gio/ginputstream.c:1391
        task = 0x7f309801b3c0
        op = 0x7f309001a580
#8 0x00007f30a793ef1a in g_input_stream_read_async (stream=0x7f3090001560, buffer=0x5643e2f49cc0, count=32777, io_priority=io_priority@entry=0, cancellable=cancellable@entry=0x0, callback=callback@entry=0x5643e167a6b0 <read_reply_async_got_data>, user_data=0x5643e2ec6148) at ../../../gio/ginputstream.c:633
        class = 0x7f309000a5d0
        error = 0x0
        __FUNCTION__ = "g_input_stream_read_async"
#9 0x00005643e167a640 in read_reply_async_got_len (source_object=0x7f3090001560, result=<optimized out>, user_data=0x5643e2ec6148) at ../daemon/gvfsbackendsftp.c:1502
        conn = 0x5643e2ec6148
        res = <optimized out>
        error = 0x0
#10 0x00007f30a793fd2b in async_ready_callback_wrapper (source_object=0x7f3090001560, res=0x7f3098003d60, user_data=0x5643e2ec6148) at ../../../gio/ginputstream.c:532
        stream = 0x7f3090001560
#11 0x00007f30a7974029 in g_task_return_now (task=0x7f3098003d60) at ../../../gio/gtask.c:1212
No locals.'

It looks like an upstream issue and you would probaly have more chance to get a reply on https://gitlab.gnome.org/GNOME/gvfs/issues if you could sent it there?

[Julien Olivier (julo)]

Here it is: https://gitlab.gnome.org/GNOME/gvfs/issues/434

[Sebastien Bacher (seb128)]

Thanks for sending the report to GNOME! One extra question to make sure the bug is correctly undestood, issue is happening on the client side right? (the computer you are using to copy file to another/server one)?

[Julien Olivier (julo)]

Yes, the bug happens on the client side, when trying to download files from a server.

[meteficha (felipe-lessa)]

@seb128: Ondrej Holy says on the upstream ticket that this issue has already been fixed upstream in glib 2.62.2. Is there a way of asking for glib to get upgraded? Thanks!

[Sebastien Bacher (seb128)]

Great, the new glib is available there https://launchpad.net/ubuntu/+source/glib2.0/2.62.2-2~ubuntu19.10.1

It should be moving this week into regular updates