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 668477 - writing to file on sftp mount causes 100% cpu usage
writing to file on sftp mount causes 100% cpu usage
Status: RESOLVED DUPLICATE of bug 776824
Product: gvfs
Classification: Core
Component: sftp backend
unspecified
Other Linux
: High critical
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2012-01-23 09:03 UTC by Paolo Benvenuto
Modified: 2017-06-07 11:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdb.log from proposed procedure (1.18 KB, text/x-log)
2017-06-07 11:08 UTC, Paolo Benvenuto
Details
gvfsd.log from proposed procedure (62.82 KB, text/x-log)
2017-06-07 11:10 UTC, Paolo Benvenuto
Details

Description Paolo Benvenuto 2012-01-23 09:03:41 UTC
I run gthumb (2.13.1), and I go to a ssh-mounted directory

I select an image, and I Tools -> resize (55% x 55%) => gthumb asks me whether overwriting it, and issueing ok it begins eating endlessly 100% cpu time, and I must kill it manually.

Same thing if I select more than one image.

Same thing if I use the resize tool in image editing mode.

I'm quite sure it's a long time bug.

I can't verify it on 2.14, It's not packaged for ubuntu at the moment.
Comment 1 Michael Chudobiak 2015-12-18 14:55:37 UTC
Marking as obsolete, as this was reported for a now-unsupported version and no recent activity has occurred. 

Please feel free to reopen this bug report if the problem still occurs with a current version of gThumb.
Comment 2 Paolo Benvenuto 2015-12-21 09:59:47 UTC
3.4.0: gthumb freezes if resizing one image on an sftp mount directory
Comment 3 Michael Chudobiak 2015-12-23 14:00:46 UTC
Confirmed in 3.4.1:

Program received signal SIGPIPE, Broken pipe.
0x00007ffff49424ed in write () at ../sysdeps/unix/syscall-template.S:81
81	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)


Thread 1 (Thread 0x7ffff7f969c0 (LWP 9538))

  • #0 write
    at ../sysdeps/unix/syscall-template.S line 81
  • #1 g_unix_output_stream_write
    at gunixoutputstream.c line 367
  • #2 write_async_pollable
    at goutputstream.c line 1789
  • #3 g_output_stream_real_write_async
    at goutputstream.c line 1832
  • #4 g_output_stream_write_async
    at goutputstream.c line 845
  • #5 async_iterate
    at gdaemonfileoutputstream.c line 1562
  • #6 g_output_stream_write_async
    at goutputstream.c line 845
  • #7 write_file__stream_write_ready_cb
    at gio-utils.c line 2335
  • #8 g_task_return_now
    at gtask.c line 1088
  • #9 g_task_return
    at gtask.c line 1146
  • #10 async_ready_write_callback_wrapper
    at goutputstream.c line 750
  • #11 g_simple_async_result_complete
    at gsimpleasyncresult.c line 763
  • #12 async_write_done
    at gdaemonfileoutputstream.c line 1633
  • #13 async_iterator_done
    at gdaemonfileoutputstream.c line 1422
  • #14 async_iterate
    at gdaemonfileoutputstream.c line 1538
  • #15 async_op_handle
    at gdaemonfileoutputstream.c line 1473
  • #16 async_read_op_callback
    at gdaemonfileoutputstream.c line 1487
  • #17 async_ready_callback_wrapper
    at ginputstream.c line 529
  • #18 g_task_return_now
    at gtask.c line 1088
  • #19 complete_in_idle_cb
    at gtask.c line 1102
  • #20 g_main_context_dispatch
    at gmain.c line 3122
  • #21 g_main_context_dispatch
    at gmain.c line 3737
  • #22 g_main_context_iterate
    at gmain.c line 3808
  • #23 g_main_context_iteration
    at gmain.c line 3869
  • #24 g_application_run
    at gapplication.c line 2308
  • #25 main
    at main.c line 493

Comment 4 Michael Chudobiak 2015-12-23 14:07:18 UTC
The sftp mount also disappears from nautilus and the gThumb sidebar... probably a glib/gio bug?

To reproduce:

1) In nautilus, click "connect to server" and connect to a server for which you have ssh access, like "sftp://root@192.168.0.200".

2) Open gThumb. The mounted sftp folder should appear in the sidebar. Open it.

3) Ctrl+click an image to select it (but not open it).

4) Click the Tools icon.

5) Click "Resize images".

6) Set width/height to 50%.

7) Click "execute".

8) Select "overwrite" in the overwrite dialog.

8) gThumb hangs, cpu at 100%.
Comment 5 Michael Chudobiak 2015-12-23 14:11:19 UTC
Versions:

glib2-2.44.1-2.fc22.x86_64

gthumb 3.4.1, and gthumb git master
Comment 6 Ondrej Holy 2017-06-06 11:13:02 UTC
sftp backend crashed probably if the mount disappeared from Nautilus. I can't reproduce it with current versions, is this still an issue?
Comment 7 Paolo Benvenuto 2017-06-06 13:03:21 UTC
gthumb 3.5.1, libglib2 2.48.2-0ubuntu1

issue still present:

when gthumb tries to actually resize the image (i.e. write) on the remote dir, the remote dir mount disappear from nautilus, and gthumb hangs with 100% cpu usage.

I would change status from needinfo, but only resolved is given as a possibility
Comment 8 Ondrej Holy 2017-06-07 08:50:35 UTC
Hmm, can you please try to obtain gvfs debug log and backtrace for gvfsd-sftp? You can do it the following way:

1/ pkill nautilus; pkill -f gvfs; GVFS_DEBUG=1 $(find /usr/lib* -name gvfsd 2>/dev/null) > gvfsd.log 2>&1
2/ connect to your sftp share as usual (e.g. gvfs-mount sftp://user@server/)
3/ gdb -p $(pidof gvfsd-sftp) --ex "set confirm off" --ex "continue" --ex "thread apply all bt" --ex "quit" > gdb.log
(it expects that you have installed all necessary debug packages)
5/ try to reproduce the problem

I suppose that the backend crashes at this point...

6/ pkill -f gvfs
7/ please attach gvfsd.log and gdb.log
Comment 9 Paolo Benvenuto 2017-06-07 11:08:49 UTC
Created attachment 353311 [details]
gdb.log from proposed procedure
Comment 10 Paolo Benvenuto 2017-06-07 11:10:14 UTC
Created attachment 353312 [details]
gvfsd.log from proposed procedure
Comment 11 Ondrej Holy 2017-06-07 11:24:16 UTC
Thanks, so the backend does not crash itself, but the underlying ssh project exited unexpectedy. This is probably duplicate of Bug 776824. What is your gvfs version?
Comment 12 Paolo Benvenuto 2017-06-07 11:28:50 UTC
$ aptitude show gvfs 
Pacchetto: gvfs                                     
Stato: installato
Installato automaticamente: no
Multi-Arch: same
Versione: 1.28.2-1ubuntu1~16.04.1
Priorità: opzionale
Sezione: libs
Responsabile: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architettura: amd64
Dimensione pacchetto installato: 632 k
Dipende: libc6 (>= 2.14), libglib2.0-0 (>= 2.45.7), gvfs-daemons (>= 1.28.2-1ubuntu1~16.04.1), gvfs-daemons (< 1.28.2-1ubuntu1~16.04.1.1~), gvfs-libs (= 1.28.2-1ubuntu1~16.04.1), gvfs-common (= 1.28.2-1ubuntu1~16.04.1)
Consiglia: gvfs-backends
Rende difettoso: gvfs:i386 (!= 1.28.2-1ubuntu1~16.04.1)
Sostituisce: gvfs:i386 (< 1.28.2-1ubuntu1~16.04.1)
Descrizione: file system virtuale in spazio utente - modulo GIO
 gvfs è un file system virtuale in spazio utente in cui i montaggi vengono eseguiti come processi separati con i quali si comunica tramite D-Bus. Contiene anche un modulo gio che aggiunge in maniera pulita il supporto gvfs a tutte le applicazioni che usano l'API gio.
 Usando fuse può anche esporre i montaggi gvfs ad applicazioni non-gio. 
 
 Questo pacchetto contiene il modulo GIO che permette alle applicazioni di usare montaggi gvfs.
Homepage: https://wiki.gnome.org/Projects/gvfs
Comment 13 Ondrej Holy 2017-06-07 11:51:31 UTC
Ok, this should be fixed in 1.28.4, but it seems that Ubuntu 16.04 is on 1.28.2 :-( You should convince the downstream maintainers to update it, or update yourself to Ubuntu 17.04... please reopen if it doesn't help to you.

*** This bug has been marked as a duplicate of bug 776824 ***