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 710490 - gvfsd-afp-browse consuming 100% cpu
gvfsd-afp-browse consuming 100% cpu
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: afp backend
1.18.x
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
: 710556 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-19 02:55 UTC by Lionel Landwerlin
Modified: 2015-09-07 11:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
afpconnection: Fix 100% cpu consumption when connection is closed remotely (880 bytes, patch)
2013-10-19 23:12 UTC, Lionel Landwerlin
needs-work Details | Review
afp: Don't retry read if connection closes (1.08 KB, patch)
2013-10-20 10:28 UTC, Ross Lagerwall
needs-work Details | Review
afp: Don't retry read if connection closes (2.29 KB, patch)
2014-08-03 09:51 UTC, Ross Lagerwall
committed Details | Review
exit silently if connection closed (1.49 KB, patch)
2015-02-27 09:43 UTC, Ondrej Holy
reviewed Details | Review
afp: exit silently if connection closed (2.04 KB, patch)
2015-03-02 12:11 UTC, Ondrej Holy
committed Details | Review
afp: exit silently if connection closed (gnome-3-14) (2.02 KB, patch)
2015-03-03 14:03 UTC, Ondrej Holy
committed Details | Review

Description Lionel Landwerlin 2013-10-19 02:55:21 UTC
My cpu's fan is getting noisy and I just noticed gvfsd-afp-browse consuming 100% cpu. I can't tell exactly what it's doing so I attached gdb and break a few times to see what code path was hit. Here is the result : 


0x00007f7b931272ba in g_private_get_impl (key=0x7f7b9339eb40 <private_thread_memory>) at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gthread-posix.c:994
994	/build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gthread-posix.c: No such file or directory.
(gdb) bt
  • #0 g_private_get_impl
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gthread-posix.c line 994
  • #1 g_private_get
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gthread-posix.c line 1025
  • #2 thread_memory_from_self
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gslice.c line 513
  • #3 g_slice_alloc
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gslice.c line 994
  • #4 g_slice_alloc0
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gslice.c line 1042
  • #5 g_input_stream_real_read_async
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 1148
  • #6 g_input_stream_read_async
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 620
  • #7 read_all_cb
    at gvfsafpconnection.c line 887
  • #8 async_ready_callback_wrapper
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 519
  • #9 g_task_return_now
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gtask.c line 1108
  • #10 complete_in_idle_cb
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gtask.c line 1117
  • #11 g_main_dispatch
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3065
  • #12 g_main_context_dispatch
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3641
  • #13 g_main_context_iterate
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3712
  • #14 g_main_loop_run
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3906
  • #15 daemon_main
    at daemon-main.c line 405
  • #16 main
    at daemon-main-generic.c line 42
  • #0 __libc_recv
    at ../sysdeps/unix/sysv/linux/x86_64/recv.c line 33
  • #1 recv
    at /usr/include/x86_64-linux-gnu/bits/socket2.h line 44
  • #2 g_socket_receive_with_blocking
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gsocket.c line 2597
  • #3 read_async_pollable
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 1107
  • #4 g_input_stream_real_read_async
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 1156
  • #5 g_input_stream_read_async
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 620
  • #6 read_all_cb
    at gvfsafpconnection.c line 887
  • #7 async_ready_callback_wrapper
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 519
  • #8 g_task_return_now
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gtask.c line 1108
  • #9 complete_in_idle_cb
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gtask.c line 1117
  • #10 g_main_dispatch
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3065
  • #11 g_main_context_dispatch
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3641
  • #12 g_main_context_iterate
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3712
  • #13 g_main_loop_run
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3906
  • #14 daemon_main
    at daemon-main.c line 405
  • #15 main
    at daemon-main-generic.c line 42
  • #0 ??
  • #1 ??
  • #2 ??
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 ??
  • #7 ??
  • #8 ??
  • #9 clock_gettime
    at ../sysdeps/unix/clock_gettime.c line 115
  • #10 g_get_monotonic_time
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 2547
  • #11 g_source_get_time
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 4245
  • #12 g_task_new
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gtask.c line 703
  • #13 g_input_stream_real_read_async
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 1149
  • #14 g_input_stream_read_async
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 620
  • #15 read_all_cb
    at gvfsafpconnection.c line 887
  • #16 async_ready_callback_wrapper
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/ginputstream.c line 519
  • #17 g_task_return_now
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gtask.c line 1108
  • #18 complete_in_idle_cb
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gtask.c line 1117
  • #19 g_main_dispatch
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3065
  • #20 g_main_context_dispatch
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3641
  • #21 g_main_context_iterate
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3712
  • #22 g_main_loop_run
    at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c line 3906
  • #23 daemon_main
    at daemon-main.c line 405
  • #24 main
    at daemon-main-generic.c line 42

Comment 1 Ross Lagerwall 2013-10-19 04:49:05 UTC
I don't know the afpconnection code but it looks like read_all_cb in gvfsafpconnection.c does not handle reading 0 (i.e. EOF) from g_input_stream_read_finish which makes it spin endlessly.
Comment 2 Lionel Landwerlin 2013-10-19 23:12:11 UTC
Created attachment 257731 [details] [review]
afpconnection: Fix 100% cpu consumption when connection is closed remotely

Well spotted!
Comment 3 Ross Lagerwall 2013-10-20 05:44:59 UTC
Review of attachment 257731 [details] [review]:

If g_input_stream_read_finish() returns 0, it isn't really an error condition and error is not set so I'm not sure if calling g_simple_async_result_take_error() is a good idea in that case.
Comment 4 Ross Lagerwall 2013-10-20 10:28:47 UTC
Created attachment 257742 [details] [review]
afp: Don't retry read if connection closes
Comment 5 Ross Lagerwall 2013-10-20 10:30:26 UTC
The attached patch sets the error condition manually if the connection closes and bytes are still expected.
Comment 6 Carl-Anton Ingmarsson 2013-10-20 17:28:30 UTC
*** Bug 710556 has been marked as a duplicate of this bug. ***
Comment 7 Carl-Anton Ingmarsson 2013-10-20 18:04:01 UTC
Review of attachment 257742 [details] [review]:

I think we also have to change the the callers of read_all_finish() to not just do g_warning() and continue as nothing happened.
For now I think the following should do:
1) Do "clean" shutdown on EOS, eg. shutdown using exit(). Print some debug output too.
2) Error out using g_error() on other errors.

Doing proper shutdown on errors requires bigger changes which I may or may not get to some day :P
Comment 8 Carl-Anton Ingmarsson 2013-10-20 18:04:43 UTC
Review of attachment 257742 [details] [review]:

I think we also have to change the the callers of read_all_finish() to not just do g_warning() and continue as nothing happened.
For now I think the following should do:
1) Do "clean" shutdown on EOS, eg. shutdown using exit(). Print some debug output too.
2) Error out using g_error() on other errors.

Doing proper shutdown on errors requires bigger changes which I may or may not get to some day :P
Comment 9 Ross Lagerwall 2013-11-11 20:14:48 UTC
(In reply to comment #8)
> Review of attachment 257742 [details] [review]:
> 
> I think we also have to change the the callers of read_all_finish() to not just
> do g_warning() and continue as nothing happened.
> For now I think the following should do:
> 1) Do "clean" shutdown on EOS, eg. shutdown using exit(). Print some debug
> output too.
> 2) Error out using g_error() on other errors.
> 

As the afp backend expert, it would probably be better if you could work on a patch that does this? Thanks
Comment 10 Ross Lagerwall 2014-08-03 09:51:08 UTC
Created attachment 282403 [details] [review]
afp: Don't retry read if connection closes

Don't retry the read if the remote host closes the connection.  Instead,
exit (semi-)gracefully with exit(0) and exit with an error if there was
an actual error.
Comment 11 Ross Lagerwall 2014-08-03 09:52:07 UTC
(In reply to comment #8)
> I think we also have to change the the callers of read_all_finish() to not just
> do g_warning() and continue as nothing happened.
> For now I think the following should do:
> 1) Do "clean" shutdown on EOS, eg. shutdown using exit(). Print some debug
> output too.
> 2) Error out using g_error() on other errors.
> 

The latest update takes this approach and fixes the problem for me.
Comment 12 Carl-Anton Ingmarsson 2014-08-03 12:58:03 UTC
Looks good, thanks for doing all this work on the AFP backend.
Comment 13 Ross Lagerwall 2014-08-03 16:15:18 UTC
(In reply to comment #12)
> Looks good, thanks for doing all this work on the AFP backend.

No problem, thanks for the review.  If you're feeling charitable, can you take a look at bug 720806 and bug 733996.  Thanks!

Pushed to master as e9c320e49cace543450b961af32ea7ffeb8d512f.
Comment 14 Ondrej Holy 2014-08-15 16:20:29 UTC
Review of attachment 282403 [details] [review]:

::: daemon/gvfsafpconnection.c
@@ +1060,3 @@
+    {
+      g_message (_("Host closed connection"));
+      exit(0);

Shouldn't be there g_vfs_backend_force_unmount() instead of exit()?

@@ +1101,3 @@
+    {
+      g_message (_("Host closed connection"));
+      exit(0);

dtto
Comment 15 Ross Lagerwall 2014-08-15 17:00:12 UTC
The problem is that after force_unmount, execution continues and the afp framework isn't geared to handle that. As Carl noted in comment 8, "Doing proper shutdown on errors requires bigger changes which I may or may not
get to some day :P".
Comment 16 lutinmalicieu 2014-09-30 10:14:10 UTC
I've the same problem on ubuntu 14.04 64b (3.13.0-36-generic) connect to Synologie NAS with Nautilus = 100% CPU activity because of gvfs-afp and gvfs-browse. Sometime I've difficulty to unmount and have the message "unable to unmount because of the broken pipe error". I've to kill the process or reboot the computer...
Comment 17 Ross Lagerwall 2014-09-30 12:00:22 UTC
Well that's because Ubuntu 14.04 doesn't have the version with the fix in it.  File a bug with the distro and ask for them to update to 1.20.3 or add the patch manually.
Comment 18 lutinmalicieu 2014-10-20 15:51:23 UTC
(In reply to comment #17)
> Well that's because Ubuntu 14.04 doesn't have the version with the fix in it. 
> File a bug with the distro and ask for them to update to 1.20.3 or add the
> patch manually.

Ok, thank you
Comment 19 Ondrej Holy 2015-02-27 09:42:50 UTC
Now there is about 20 abrt reports per week:
https://retrace.fedoraproject.org/faf2/reports/424585/
https://bugzilla.redhat.com/show_bug.cgi?id=1173722

probably because:
msg = 0x1315630 "FAIL!!! \"Error receiving data: Connection reset by peer\"\n"

We should to exit "cleanly" also for G_IO_ERROR_CONNECTION_CLOSED.
Comment 20 Ondrej Holy 2015-02-27 09:43:29 UTC
Created attachment 298069 [details] [review]
exit silently if connection closed
Comment 21 Ross Lagerwall 2015-02-28 22:12:19 UTC
Review of attachment 298069 [details] [review]:

You need to bump the glib version to 2.43.2 for G_IO_ERROR_CONNECTION_CLOSED. Otherwise looks good.
Comment 22 Ondrej Holy 2015-03-02 12:11:24 UTC
Created attachment 298276 [details] [review]
afp: exit silently if connection closed

Thanks for the review, there is patch also with GLib version dependency bump. (But maybe it would be enough to use G_IO_ERROR_BROKEN_PIPE instead without dependency bump...)
Comment 23 Ross Lagerwall 2015-03-02 13:06:56 UTC
Review of attachment 298276 [details] [review]:

Looks good.
Comment 24 Ondrej Holy 2015-03-03 14:03:21 UTC
Created attachment 298431 [details] [review]
afp: exit silently if connection closed (gnome-3-14)

It would be nice to fix it also for F20 to avoid abrt reports, but _CONNECTION_CLOSED error isn't supported there (already realized that _CONNECTION_CLOSED patch is from year 2011, but pushed recently). Seems G_IO_ERROR_FAILED is returned instead in older versions, so I think it would be best to change g_error to g_warning for gnome-3-14... do you agree?
Comment 25 Ondrej Holy 2015-03-04 13:20:07 UTC
Comment on attachment 298276 [details] [review]
afp: exit silently if connection closed

commit 8fdf64272ec47315cdd3e12d1aa628ad3bb837bc
Comment 26 Ross Lagerwall 2015-03-04 23:18:40 UTC
Review of attachment 298431 [details] [review]:

Looks good.
Comment 27 Ondrej Holy 2015-03-05 08:09:20 UTC
Comment on attachment 298431 [details] [review]
afp: exit silently if connection closed (gnome-3-14)

I forgot to delete check for G_IO_ERROR_CONNECTION_CLOSED, what is the reason why I was doing new patch, so pushed in gnome-3-14 without it as:

commit 14369db2a8fc4f2a33e457a766b077ed6e2a3557
Comment 28 Ondrej Holy 2015-03-05 08:09:43 UTC
Thanks for reviews...
Comment 29 Ondrej Holy 2015-08-28 12:30:52 UTC
Sorry for reopening, but there are still some "crashes" caused by g_error...

It is crashing because of the following error:
"Errore nel ricevere i dati: Nessun instradamento per l'host"

In the English it is something like (not sure about the source of the error to get right translation):
"Error in receiving data: No route to host"

It is from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1246811

The error doesn't have some special code probably. I don't know the afp code, but I suppose it would be best to change the g_error to g_warning at least and exit as I have done already for gnome-3-14, what do you think?
Comment 30 Ross Lagerwall 2015-08-29 20:50:26 UTC
I guess the errror is probably either EHOSTUNREACH or ENETUNREACH caused by the network interface going down.

I cherry-picked 14369db2a8fc4f2a33e457a766b077ed6e2a3557 from gnome-3-14 and altered the commit message.

Thanks
Comment 31 Ondrej Holy 2015-09-07 11:43:08 UTC
Thanks! I've pushed it also for gnome-3-16:
commit d663c85f0356d7800638c5eaa1a49e6c26bdfa33