Thanks for the bug report. Unfortunately, that stack trace is not very useful in
determining the cause of the crash. Can you get one
(http://live.gnome.org/GettingTraces) with the libgnomevfs2-0-dbg nautilus-dbg
packages installed?

Hmm...very strange.  I presume that nautilus-dbg supplies alternative
executables that should be used in lieu of the ones supplied by the nautilus
package, yes?

If so, then nautilus-dbg seems to be a dead-in-the-water package.  When I
attempt to run the 'nautilus' executable supplied by that package, I get an
immediate core dump.  gdb of that shows:

Core was generated by `/usr/lib/debug/usr/bin/nautilus'.
Program terminated with signal 11, Segmentation fault.

+ Trace 61533

kevin@filer:~$ file /usr/lib/debug/usr/bin/nautilus
/usr/lib/debug/usr/bin/nautilus: ELF 32-bit LSB executable, Intel 80386, version
1 (SYSV), statically linked, not stripped


Did someone break that package in debian unstable?  The version I'm using is:

kevin@filer:~$ dpkg -l nautilus-dbg
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  nautilus-dbg   2.10.1-2       file manager and graphical shell for GNOME

no, nautilus-dbg provides debugging symboles which are picked by gdb when it
gets the backtrace

Here's a stacktrace with nautilus-dbg, libgnomevfs2-0-dbg, and libglib2.0-0-dbg
installed:

Backtrace was generated from '/usr/bin/nautilus'

Using host libthread_db library "/lib/tls/libthread_db.so.1".
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1224395616 (LWP 3744)]
[New Thread -1235752016 (LWP 3750)]
[New Thread -1235489872 (LWP 3749)]
[New Thread -1235227728 (LWP 3748)]
[New Thread -1225733200 (LWP 3747)]
0xb7be1561 in __waitpid_nocancel () from /lib/tls/libpthread.so.0

+ Trace 61544

thanks for the backtrace!

Did it help?

If not, is there something else I can do to give better or more useful info?

Additional details, in case they may prove relevant:

I have a system at work with the same distribution, running the same packages. 
It does *not* seem to experience the problem in question.

There might be metadata that differs between the working system and the
non-working system, but I have no idea what to check or how to check it.  Hints
on how to go about examining that would be helpful.

But since this is related to trashcan handling, there's one additional
difference between the two systems that may be relevant: the system that works
is using ext3 as the filesystem, while the system that fails is using IBM's JFS
as the filesystem.

That shouldn't make any difference, of course, since both filesystems adhere to
the same API (and are, in any case, hidden behind a VFS layer), but it may prove
noteworthy.

*** Bug 310465 has been marked as a duplicate of this bug. ***

Adjusting priority/severity and confirming.

I'm apparently hit by this, but already on login.. In our environment my $HOME
is /u/lai/lk/tjaalton, /u is a real directory and /u/lai a symlink to a
NFS-mount. On my laptop I have /u as a symlink to /home/u (because no
NFS-mounts..), and under it the rest. So, nautilus/trashapplet crash on me
_only_ if the first part of $HOME is a symlink (in this case, /u), but not if it
is a real directory...

Maybe this didn't confuse you too much ;)

*** Bug 315669 has been marked as a duplicate of this bug. ***

So, could the problem be target_uri_string=0x0 in frame #9 ?

cc'ing  Vasily Chekalkin

From Bug 315669

------- Additional Comment #5 From Vasily Chekalkin 2005-09-12 09:44 UTC ------- 

Sorry, I've removed some files in my home dir and nau doesn't crash now.

But I have other dir :)

(gdb) bt

+ Trace 62950

Vasily, what files have you moved out of the way? they triggered the crash.

are any symbolic links involved?

Are there any special files in the directory that cause your crash? 
Can you please try to identify what file(s) cause the crash?

Eeek, the crash is probably in

gnome_vfs_find_directory (vfs_uri, GNOME_VFS_DIRECTORY_KIND_TRASH,
                          &trash_vfs_uri, FALSE, FALSE, 0777)

from eel_uri_is_in_trash.

Created attachment 52119 [details]
testing program

The attached program tries to find the trash directory for a given URI. Maybe
you could compile it with
  gcc -o testcrash testcrash.c `pkg-config --libs --cflags gnome-vfs-2.0`
and then run
  ./testcrash file:///home
?

Yes. I've removed 2 files: 1 link and 1 file with "broken" name.

bacek@bacek:~/src$ gcc -g -o testcrash testcrash.c `pkg-config --libs --cflags g
nome-vfs-2.0`
bacek@bacek:~/src$ gdb ./testcrash 
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/
lib/tls/libthread_db.so.1".

(gdb) r file:///home/bacek/src
Starting program: /opt/home/bacek/src/testcrash file:///home/bacek/src
[Thread debugging using libthread_db enabled]
[New Thread -1208104736 (LWP 16241)]
** Message: finding trash directory for file:///home/bacek/src
** Message: result: Too many links

Program received signal SIGSEGV, Segmentation fault.

+ Trace 62953

May be this help too.

(gdb) up

+ Trace 62954

Thanks for your quick response!

Probably two issues:
1) gnome_vfs_find_directory failed, but trash_uri is not NULL
2) The "Too many links" problem shouldn't happen. I assume you have some looped
symlinks or something (i.e. src/foo -> src/). Also, GnomeVFS should be smarter
when symlink resolution fails.

Reassigning to GnomeVFS.

Created attachment 52123 [details] [review]
Proposed patch

The attached patch NULLifies *result_uri in
gnome_vfs_find_directory_cancellable before doing anything. Thus, we have it
set to NULL if the symlink resolution fails, or the operation is cancelled,
which happens before the GnomeVFSMethod->find_directory invocation. This also
fixes cases where modules don't set *result_uri to NULL if they fail.

I've committed that patch. It should considerably reduce the amount of issues we
have. Vasily: Maybe you could check back what happens now in Nautilus? I suspect
the item just won't be placed in the trash.

I'll try gnome-vfs with this patch. But my crash wasn't releated to drag'n'drop
and trashcan. My nau crash on open directory.

Hmm... testcrash works.

bacek@bacek:~/src$ ./testcrash file:///home/bacek/src
** Message: finding trash directory for file:///home/bacek/src
** Message: result: Too many links

** (process:1384): WARNING **: no trash found!
bacek@bacek:~/src$

But nau still crashes.
bacek@bacek:~/src$ gdb nautilus
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) r /home/bacek/src
Starting program: /usr/bin/nautilus /home/bacek/src
...
Program received signal SIGSEGV, Segmentation fault.

+ Trace 62956

Very strange...

(gdb) up

+ Trace 62957

$6 = (GnomeVFSURI *) 0x88e3d10
(gdb) p *near_uri
$7 = {ref_count = 2, text = 0x868a2a0 "/home/bacek", fragment_id = 0x0, 
  method_string = 0x868a898 "file", method = 0xb7c93700, parent = 0x0, 
  reserved1 = 0x2f74706f, reserved2 = 0x656d6f68}

Created attachment 52126 [details]
testing program 2

Thanks again for your quick response!
The attached sample program check whether
_gnome_vfs_uri_resolve_all_symlinks_uri works correctly. If it doesn't work for
file:///home/bacek/src, I would like you to tell us some details about the type
of the src/ file, where it points to if it is a symlink, how the symlink
hierarchy proceeds etc..

bacek@bacek:~/src$ ./testcrash2 file:///home/bacek/src
** Message: resolving all symlinks for file:///home/bacek/src
** Message: result: Too many links

** (process:2419): WARNING **: no URI resolved!

Ooopps...

bacek@bacek:~/src$ gdb nautilus
GNU gdb 6.3-debian
...
(gdb) r file:///home/bacek/src
Starting program: /usr/bin/nautilus file:///home/bacek/src
...
*** glibc detected *** double free or corruption (out): 0x085f58a8 ***

Program received signal SIGABRT, Aborted.

+ Trace 62959

Previous backtrace is invalid. 

Right backtrace is:

(gdb) bt

+ Trace 62962

Vasily: Running testcrash2 with file:///home/bacek crashes as well, right?

No. testcrash2 works fine.

Seems I've found a bug. May be problem in my directory structure.

This is backtrace of another crash:

Program received signal SIGSEGV, Segmentation fault.
gnome_vfs_escape_string_internal (
    string=0x86bbedd "t/home/%25D55Kt/home/%2", '5' <repeats 177 times>..., 
    mask=UNSAFE_PATH) at gnome-vfs-utils.c:233
233                             *q++ = c;
(gdb) up

+ Trace 62963

$10 = (GnomeVFSURI *) 0x83c5ff0
(gdb) p *resolved_uri 
$11 = {ref_count = 1, text = 0x8651b60 "/home/opt/home", fragment_id = 0x0, 
  method_string = 0x83a7540 "file", method = 0xb7c03700, parent = 0x0, 
  reserved1 = 0x2f74706f, reserved2 = 0x656d6f68}

This is directory layout:
bacek@bacek:/$ ls -la|grep home
lrwxrwxrwx    1 root staff     8 2005-03-02 04:10 home -> opt/home

When I invoke "$ nautilus /home/bacek/src" it freez.
OTH nautilus /opt/home/bacek/src works fine.

I'm pretty much sure it works if you rm /home && ln -s /opt/home /home

Yes. It works. But bug is still exists :)

Looks like _gnome_vfs_uri_resolve_all_symlinks_uri is hosed. I haven't
investigated it in detail, but according to some random guy on a C IRC channel
there are two types of symlinks, the ones with and the ones without a '/'
prefix. If a symlink foo *has* this prefix (foo->/opt/foo), it is meant to be
resolved to /opt/foo. If it does *not* have this prefix (foo->opt/foo), it is
meant to be resolved to opt/foo, i.e. the symlink name should replace the
basename of the symlink.

However, having the directory structure /foo->/opt/foo and invoking
_gnome_vfs_uri_resolve_all_symlinks_uri for "/foo" does not resolve to /opt/foo,
but result in an endless loop (Too many links).

Yeek. Basename for 'foo' is `pwd`/foo. And symlink foo->opt/foo must be resolved
into `pwd`/opt/foo.

Created attachment 52129 [details] [review]
Proposed patch

Could you please check whether the attached patch helps?

It will probably even be worse. Please ignore it.

Created attachment 52130 [details] [review]
Proposed patch

This patch should fix both the crasher you had and symlink resolution.

Vasily, can you confirm that this patch helps?

Created attachment 52143 [details] [review]
Proposed patch

Thanks to Christian Kellner for tracking down a typo. This one should help.
Vasily, maybe you could try it out?

Still crashing...

Most significant part of backtrace:

Program received signal SIGSEGV, Segmentation fault.

+ Trace 62973

Ah...it turns out my /home directory on the system I have which shows the issue
is indeed a symlink to export/home (i.e., a relative link).  When I change it to
point to /export/home instead (in other words, make it an absolute instead of
relative link), drag&drop into the trash works properly.

Sorry, symlink following is something that's been done for so long now that it
never even occurred to me to think of that as a relevant thing to report.  I
figured something like that Just Worked.  You guys might have made headway
against this issue much sooner had I reported that little detail.  :-(

Anyway, excellent work on tracking this one down thus far...

Vasily: I don't get why this crashes for you. I have a directory structure like
/opt
/opt/foo
/opt/foo/foobar
/opt/foo/foobar/bar
/foo -> opt/foo

replace "foo" by "home", "foobar" by "bacek" and "bar" by "src" and this should
be your situation.

For me, my test program returns

** Message: resolving all symlinks for file:///foo/foobar/bar
** Message: result: No error
** Message: resolved to URI: file:///opt/foo/foobar/bar

Does the test program also work for you?

I also find your last stack trace quiet obscure:

+ Trace 62976

means that the URI's memory address magically changed. Maybe you could add a

  g_message ("resolving %s", gnome_vfs_uri_to_string (uri,
GNOME_VFS_URI_HIDE_NONE));

to the beginning of _gnome_vfs_uri_resolve_all_symlinks_uri and tell us *what*
uri is resolved?

Ок. "I know kung-fu"

(gdb) r
Starting program: /usr/bin/nautilus file:///home/bacek/src
...
Breakpoint 1 at 0xb7f36585: file gnome-vfs-utils.c, line 1993.
libgnomevfs-Message: resolving file:///usr
[New Thread -1216754768 (LWP 11151)]
[New Thread -1217016912 (LWP 11152)]
libgnomevfs-Message: resolving file:///opt
libgnomevfs-Message: resolving file:///
libgnomevfs-Message: resolving file:///home/bacek
[Switching to Thread -1209104704 (LWP 11143)]

Breakpoint 1, _gnome_vfs_uri_resolve_all_symlinks_uri (uri=0x8518968, 
    result_uri=0xbfd68018) at gnome-vfs-utils.c:1993
1993                            new_uri_parent = gnome_vfs_uri_get_parent (uri);
(gdb) p *uri
$1 = {ref_count = 3, text = 0x875b3a8 "/home/bacek", fragment_id = 0x0, 
  method_string = 0x850ddd8 "file", method = 0xb7cc9700, parent = 0x0, 
  reserved1 = 0x85188d0, reserved2 = 0x85186c8}
(gdb) n
1994                            resolved_uri = gnome_vfs_uri_resolve_relative
(new_uri_parent,
(gdb) n
1996                            gnome_vfs_uri_unref (new_uri_parent);
(gdb) p *resolved_uri 
$2 = {ref_count = 1, text = 0x8518908 "/home/opt/home", fragment_id = 0x0, 
  method_string = 0x85166d8 "file", method = 0xb7cc9700, parent = 0x0, 
  reserved1 = 0x2f554e47, reserved2 = 0x756e694c}
(gdb) n

I think that "/home/opt/home" is wrong.

testcrash2 crashes too.

Thanks for your extensive feedback!
What is the value of p before resolved_uri is initialized?

bacek@bacek:~/src$ gdb ./testcrash2 
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library
"/lib/tls/libthread_db.so.1".

(gdb) b gnome-vfs-utils.c:1967
(gdb) r /home/bacek/src
Starting program: /opt/home/bacek/src/testcrash2 /home/bacek/src
Breakpoint 2, _gnome_vfs_uri_resolve_all_symlinks_uri (uri=0x8070ec0, 
    result_uri=0xbf7fe4a8) at gnome-vfs-utils.c:1967
1967            p = uri->text;
(gdb) n
1969            while (*p != 0) {
(gdb) p p
$1 = 0x8071a00 "/home/bacek/src"
(gdb) n

...

(gdb) p p
$2 = 0x8071a05 "/bacek/src"
(gdb) n
1979                    gnome_vfs_file_info_clear (info);
(gdb) 
1980                    res = gnome_vfs_get_file_info_uri (new_uri, info,
GNOME_VFS_FILE_INFO_DEFAULT);
(gdb) 
1981                    if (res != GNOME_VFS_OK) {
(gdb) 
1985                    if (info->type == GNOME_VFS_FILE_TYPE_SYMBOLIC_LINK &&
(gdb) 
1987                            n_followed_symlinks++;
(gdb) 
1988                            if (n_followed_symlinks > MAX_SYMLINKS_FOLLOWED) {
(gdb) 
1993                            new_uri_parent = gnome_vfs_uri_get_parent (uri);
(gdb) 
1994                            resolved_uri = gnome_vfs_uri_resolve_relative
(new_uri_parent,
(gdb) p *new_uri_parent 
$3 = {ref_count = 1, text = 0x8057bc0 "/home/bacek", fragment_id = 0x0, 
  method_string = 0x8057c00 "file", method = 0xb7efd700, parent = 0x0, 
  reserved1 = 0x0, reserved2 = 0x0}
(gdb) n
1996                            gnome_vfs_uri_unref (new_uri_parent);
(gdb) p *resolved_uri 
$4 = {ref_count = 1, text = 0x8086318 "/home/opt/home", fragment_id = 0x0, 
  method_string = 0x8057cc8 "file", method = 0xb7efd700, parent = 0x0, 
  reserved1 = 0x0, reserved2 = 0x0}

You still use my old, obsolete patch (attachment 52130 [details] [review]):
  new_uri_parent = gnome_vfs_uri_get_parent (uri);
If you use attachment 52143 [details] [review] instead, this line will be:
  new_uri_parent = gnome_vfs_uri_get_parent (new_uri);

btw. I've just tested mv /home /opt/home && ln -s opt/home /home, and it seems
to work like a charm :).

Yes!!! It works!!!

BTW, 
bacek@bacek:~$ ./src/testcrash2 src
** Message: resolving all symlinks for file:src
libgnomevfs-Message: resolving file:src
** Message: result: Invalid URI

** (process:31838): WARNING **: no URI resolved!

Is this behavior correct?

Vasily: Yes, this is at least partially correct. The application was written so
that it takes a full URI. However, it obviously tries to construct a weirdo
file:yourinput URI if it fails.

I've committed the patch that helps, which will also be incorporated in GnomeVFS
2.12. Thus, I'm marking this bug as FIXED.

Kevin: If you still get this issue, please reopen this bug report.

*** Bug 312536 has been marked as a duplicate of this bug. ***

*** Bug 334712 has been marked as a duplicate of this bug. ***