Bug 616145 - nautilus uses 100% CPU viewing Wastebasket
nautilus uses 100% CPU viewing Wastebasket
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gvfs (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Tomáš Bžatek
desktop-bugs@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-19 14:18 EDT by Tim Waugh
Modified: 2017-02-06 09:35 EST (History)
3 users (show)

See Also:
Fixed In Version: gvfs-1.4.3-10.el6
Doc Type: Bug Fix
Doc Text:
Cause: There was a bug in parsing d-bus communication in the enumeration code Consequence: Viewing certain folders with affected items resulted in endless loop in client application (the client side of gvfs). Fix: gvfs client code has been fixed Result: Client applications no longer freeze
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 09:02:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
trash.tar.xz (352 bytes, text/plain)
2010-08-25 12:41 EDT, Tim Waugh
no flags Details
gvfs-wastebasket-busyloop.patch (521 bytes, patch)
2010-08-26 12:46 EDT, Tim Waugh
no flags Details | Diff

  None (edit)
Description Tim Waugh 2010-07-19 14:18:04 EDT
Description of problem:
The nautilus process becomes unresponsive when I try to view the wastebasket.  Here's a backtrace:

#0  0x000000303807856d in _int_malloc (av=0x303837ae80, bytes=37)
    at malloc.c:4287
#1  0x0000003038079afd in __libc_malloc (bytes=37) at malloc.c:3660
#2  0x0000003037c417d3 in IA__g_malloc (n_bytes=37) at gmem.c:132
#3  0x0000003037c58fce in IA__g_strdup (str=
    0x87c3770 "unconfined_u:object_r:user_home_t:s0") at gstrfuncs.c:102
#4  0x000000303ac318ad in _g_file_attribute_value_set_from_pointer (value=
    0x87c7690, type=G_FILE_ATTRIBUTE_TYPE_STRING, value_p=0x87c3770, dup=1)
    at gfileattribute.c:662
#5  0x00007fb303575266 in _g_dbus_get_file_info (iter=0x7fff36e59b30, error=
    0x0) at gvfsdaemonprotocol.c:505
#6  0x00007fb30335273b in g_daemon_file_enumerator_dbus_filter (
    connection=<value optimized out>, message=<value optimized out>, user_data=
    0x2027dc0) at gdaemonfileenumerator.c:328
#7  0x00007fb3033531f5 in vfs_connection_filter (connection=0x1d2a030, message=
    0x7fb2fc016110, user_data=<value optimized out>) at gvfsdaemondbus.c:178
#8  0x000000303c0109d6 in dbus_connection_dispatch (connection=0x1d2a030)
    at dbus-connection.c:4451
#9  0x00007fb30356e945 in dbus_source_dispatch (source=<value optimized out>, 
    callback=<value optimized out>, user_data=<value optimized out>)
    at gdbusutils.c:810
#10 0x0000003037c38f0e in g_main_dispatch (context=0x1b94aa0) at gmain.c:1960
#11 IA__g_main_context_dispatch (context=0x1b94aa0) at gmain.c:2513
#12 0x0000003037c3c938 in g_main_context_iterate (context=0x1b94aa0, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2591
#13 0x0000003037c3cd55 in IA__g_main_loop_run (loop=0x1d2b600) at gmain.c:2799
#14 0x000000303ed4c287 in IA__gtk_main () at gtkmain.c:1218
#15 0x0000000000440eba in main (argc=1, argv=0x7fff36e5a218)
    at nautilus-main.c:544

strace just shows this:

brk(0x8a03000)                          = 0x8a03000
brk(0x8a02000)                          = 0x8a02000
brk(0x8a23000)                          = 0x8a23000
brk(0x8a22000)                          = 0x8a22000
brk(0x8a43000)                          = 0x8a43000
brk(0x8a42000)                          = 0x8a42000
brk(0x8a63000)                          = 0x8a63000
brk(0x8a62000)                          = 0x8a62000
brk(0x8a83000)                          = 0x8a83000
brk(0x8a82000)                          = 0x8a82000
brk(0x8aa3000)                          = 0x8aa3000
brk(0x8aa2000)                          = 0x8aa2000
brk(0x8ac3000)                          = 0x8ac3000
brk(0x8ac2000)                          = 0x8ac2000
brk(0x8ae3000)                          = 0x8ae3000
brk(0x8ae2000)                          = 0x8ae2000
... i.e. it's gradually growing in size.

Version-Release number of selected component (if applicable):
nautilus-2.28.4-14.el6.x86_64
gvfs-1.4.3-9.el6.x86_64

How reproducible:
Every time.
Comment 1 Tomáš Bžatek 2010-07-20 12:36:21 EDT
We've had similar problem some time ago: https://bugzilla.gnome.org/show_bug.cgi?id=614544

Not sure if it's related, your backtrace looks to be duping selinux context. How did you manage to get to this state? Is this easily reproducible? The bug mentioned above was triggered by setting an emblem on a directory and deleting it afterwards.
Comment 2 Tim Waugh 2010-08-22 09:09:59 EDT
I don't know.  How can I debug it?
Comment 3 Tomáš Bžatek 2010-08-25 10:22:37 EDT
Does it work when you turn selinux off? Does `gvfs-ls -lh trash:///` work?

Usually there's a trash per mount, a directory .Trash at the root of each partition or mount. Except of / naturally. The trash you see on the desktop is a mixture of all these trashes plus ~/.local/share/Trash so it's hard to distinguish where the bad files really are. But you can try to renaming one by one to find the affected trash. If possible, would be great to have those files here for debugging.

The bug mentioned above was related to metadata, e.g. emblems set to some files. Rawhide nautilus now ignores emblems and *might* work.
Comment 4 Tim Waugh 2010-08-25 12:41:13 EDT
Created attachment 440992 [details]
trash.tar.xz

It's ~/.local/share/Trash.  I've managed to narrow it down to a single directory.  I can't really see what makes it special though.

There is no ~/Desktop/pics/Gardens directory, although creating one makes no difference.

Yes, gvfs-ls works fine.
Comment 6 Tomáš Bžatek 2010-08-26 09:39:00 EDT
Thanks for finding that out. It works fine here and there's nothing bad in trashinfo file either. So there's two options left - metadata associated with the file or a selinux context.

Can you do `ls -alZR ~/.local/share/Trash` and also `gvfs-info trash:///Gardens` please?
Comment 7 Tim Waugh 2010-08-26 12:43:45 EDT
The test case is no longer working for me.  Not only that, but starting from the same set of files I originally did I can now track it down to a separate directory... however, I have no doubt that will behave in the same way.

Here's what I get from gvfs-info:

$ gvfs-info trash:///Tour
Error getting info: Invalid file info format

$ gvfs-ls -lh trash:///
Boardwalk	4096	(directory)
Exbury	4096	(directory)
Tour	4096	(directory)

After double-clicking on the wastebasket icon, nautilus goes into a busy loop.  Here is the stack trace:

#0  g_daemon_file_enumerator_dbus_filter (connection=<value optimized out>, 
    message=<value optimized out>, user_data=0x27e5ee0)
    at gdaemonfileenumerator.c:329
#1  0x00007fd57c26b1f5 in vfs_connection_filter (connection=0x26b0f20, message=
    0x28da690, user_data=<value optimized out>) at gvfsdaemondbus.c:178
#2  0x0000003e426109d6 in dbus_connection_dispatch (connection=0x26b0f20)
    at dbus-connection.c:4451
#3  0x00007fd57c486945 in dbus_source_dispatch (source=<value optimized out>, 
    callback=<value optimized out>, user_data=<value optimized out>)
    at gdbusutils.c:810
#4  0x0000003e3fe38f0e in g_main_dispatch (context=0x2439aa0) at gmain.c:1960
#5  IA__g_main_context_dispatch (context=0x2439aa0) at gmain.c:2513
#6  0x0000003e3fe3c938 in g_main_context_iterate (context=0x2439aa0, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2591
#7  0x0000003e3fe3cd55 in IA__g_main_loop_run (loop=0x25d0320) at gmain.c:2799
#8  0x0000003e4674c287 in IA__gtk_main () at gtkmain.c:1218
#9  0x0000000000440eba in main (argc=1, argv=0x7fff705c2138)
    at nautilus-main.c:544

enumerator = 0x27e5ee0 [GDaemonFileEnumerator]
member = <value optimized out>
iter = {dummy1 = 0x28da690, dummy2 = 0x3900600000, dummy3 = 108, dummy4 = 0, 
  dummy5 = 42837656, dummy6 = 0, dummy7 = 126, dummy8 = 0, dummy9 = 42837720, 
  dummy10 = 0, dummy11 = 6429, pad1 = 0, pad2 = 1115945856, pad3 = 0x27f2ad0}
array_iter = {dummy1 = 0x28da690, dummy2 = 0x3900600000, dummy3 = 2156, 
  dummy4 = 0, dummy5 = 42837656, dummy6 = 0, dummy7 = 118, dummy8 = 0, 
  dummy9 = 42837720, dummy10 = 0, dummy11 = 8, pad1 = 0, pad2 = 1115945664, 
  pad3 = 0x8}
infos = 0x0
info = 0x0
__PRETTY_FUNCTION__ = "g_daemon_file_enumerator_dbus_filter"

Stepping through it:

326		  while (dbus_message_iter_get_arg_type (&array_iter) == DBUS_TYPE_STRUCT)
Value returned is $18 = 114
(which is 'r', which is DBUS_TYPE_STRUCT)

328		      info = _g_dbus_get_file_info (&array_iter, NULL);
329		      if (info)
Value returned is $20 = (GFileInfo *) 0x0
335		      dbus_message_iter_next (&iter);



Hey, that's a different iter.
Comment 8 Tim Waugh 2010-08-26 12:46:48 EDT
Created attachment 441275 [details]
gvfs-wastebasket-busyloop.patch

Untested patch.
Comment 9 Tim Waugh 2010-08-26 13:22:27 EDT
Fixes it here.
Comment 10 Tomáš Bžatek 2010-08-27 04:44:42 EDT
Thanks for the patch, it's basically what I found while debugging https://bugzilla.gnome.org/show_bug.cgi?id=614544. We have that upstream for some time and it looks it works fine. I was originally puzzled by your first backtrace, looked like a different issue.
Comment 13 Denise Dumas 2010-08-27 11:48:15 EDT
Proposing for zstream
Comment 17 Tomáš Bžatek 2011-04-11 11:32:12 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: There was a bug in parsing d-bus communication in the enumeration code

Consequence: Viewing certain folders with affected items resulted in endless loop in client application (the client side of gvfs).

Fix: gvfs client code has been fixed

Result: Client applications no longer freeze
Comment 18 errata-xmlrpc 2011-05-19 09:02:50 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0536.html

Note You need to log in before you can comment on or make changes to this bug.