Bug 616145

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.

I don't know.  How can I debug it?

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.

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.

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?

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.

Created attachment 441275 [details]
gvfs-wastebasket-busyloop.patch

Untested patch.

Fixes it here.

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.

Proposing for zstream

    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

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