Appears to be a unique stack trace, according to the simple-dup-finder.

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

I'm still experiencing systematically this bug with gthumb 2.6.1.

Distribution: Debian 3.1
Package: gthumb
Version:  2.6.1

I thought this might be a useful information.

Here is a proper backtrace :

Program received signal SIGSEGV, Segmentation fault.

+ Trace 53078

Some symlinks seem to be involved.
And I actually have some symlinks in the directory that triggers the bug.

Let's try to move them elsewhere...
Yay ! it works !

I checked: the symlinks are not looping

==> Conclusion 1: if I remove the symlinks from the directory, I can't reproduce
the crash anymore.

The symlinks are relative, let's make them absolute !
=> no crash !

==> Conclusion 2: if I change the relative symlinks to absolute, I can't
reproduce the crash anymore.

I recompiled libgnomevfs with debug enabled :

(gdb) bt

+ Trace 53083

gnome-vfs-uri.c:1108 is the following :

gchar *
gnome_vfs_uri_to_string (const GnomeVFSURI *uri,
                         GnomeVFSURIHideOptions hide_options)
{
        GString *string;
        gchar *result;

==>     string = g_string_new (uri->method_string);
        g_string_append_c (string, ':');

        if (uri->parent == NULL) {
                GnomeVFSToplevelURI *top_level_uri = (GnomeVFSToplevelURI *)uri;
                gboolean shown_user_pass = FALSE;

Maybe uri is NULL ?

The call to gnome_vfs_uri_to_string seems to be around line 1670 in
libgthumb/file-utils.c :

           res = GNOME_VFS_ERROR_TOO_MANY_LINKS;
                                gnome_vfs_uri_unref (new_uri);
                                goto out;
                        }

                        resolved_uri = gnome_vfs_uri_resolve_relative (new_uri,
info->symlink_name);
==>                        tmp_resolved_text_uri = new_path_from_uri (resolved_uri);
                        gnome_vfs_uri_unref (resolved_uri);


Perhaps resolved_uri (returned by gnome_vfs_uri_resolve_relative), is NULL ?


This bug should perhaps be requalified as a gnomevfs bug ??

Digging a bit more :

in gnome_vfs_uri_resolve_relative (gnome-vfs-uri.c , line 869) :

        if (is_uri_relative (relative_reference)) {
                text_new = make_full_uri_from_relative (text_base,
                                                        relative_reference);
        } else {
                text_new = g_strdup (relative_reference);
        }

This maybe where the type of my symlinks (relative or absolute) trigger the bug
or not.

make_full_uri_from_relative might be the culprit ?

Last comment is misleading.

I traceed with ddd, and though the link is relative, is_uri_relative returns
false.  Looking at the source and my symlink name makes it obvious why :  the
relative name of the symlink contains a colon (":") and is_uri_relative takes
this as a uri method separator, and thus concludes the link is relative.

Now I have the following testcase :


home:/tmp/testcase% find | xargs ls -ld                                        
     
drwxrwxr-x  6 tom tom 120 2004-12-03 19:30 .
drwxrwxr-x  2 tom tom  80 2004-12-03 19:23 ./dir-1
lrwxrwxrwx  1 tom tom   8 2004-12-03 19:23 ./dir-1/ab.jpg -> test.jgp
-rw-r--r--  1 tom tom 374 2004-12-03 19:22 ./dir-1/test.jgp
drwxrwxr-x  2 tom tom  80 2004-12-03 19:23 ./dir-2
lrwxrwxrwx  1 tom tom   8 2004-12-03 19:23 ./dir-2/a:b.jpg -> test.jgp
-rw-r--r--  1 tom tom 374 2004-12-03 19:23 ./dir-2/test.jgp
drwxrwxr-x  3 tom tom  80 2004-12-03 19:29 ./dir-3
drwxrwxr-x  2 tom tom  60 2004-12-03 19:29 ./dir-3/a:b
-rw-r--r--  1 tom tom 374 2004-12-03 19:29 ./dir-3/a:b/test.jgp
lrwxrwxrwx  1 tom tom  12 2004-12-03 19:29 ./dir-3/test.jgp -> a:b/test.jgp
drwxrwxr-x  3 tom tom  80 2004-12-03 19:30 ./dir-4
drwxrwxr-x  2 tom tom  60 2004-12-03 19:30 ./dir-4/a:b
-rw-r--r--  1 tom tom 374 2004-12-03 19:30 ./dir-4/a:b/c:d.jpg
lrwxrwxrwx  1 tom tom  11 2004-12-03 19:30 ./dir-4/test.jpg -> a:b/c:d.jpg

dir-1, dir-2 and dir-3 do not make gthumb crash
dir-4 does

I'm requalying this bug as a gnomevfs bug.
Clearly the bug is in is_uri_relative (gnome-vfs-uri.c).

Is it really required to let people put Gnome URI in POSIX symlinks ??
There clearly is something broken here.. IMHO !

If I create the following symlink :

a -> http://www.foo.org/index.html

Then there is two ways to interpret it : is it a local relative symlink to a
file with that name, or a GnomeURI-symlink (whatever that is) to the
corresponding HTTP URI ???

Let's test relative Gnome-URI-style symlinks, e.g. :

test.jpg -> http://localhost/test.jpg       
hosts -> file:///etc/hosts
test.jpg -> file:///var/www/test.jpg

All of these are seen by nautilus as broken links (though the target files
exists if interpreted as URIs), same for Eog or Gthumb. Gedit enters into an
endless loop when I try to open the test "hosts" test link with it.

A quick conclusion would be to say that this feature (letting symlink targets be
interpreted as Gnome URIs) is buggy or not supported by applications (at least
not in the usual "transparent" way of GnomeVFS). 

I think is_uri_relative should be changed and only test for the first character
 of uri not being '/'.

Special characters in URIs (like :, #, ...) generally need to be escaped before
being passed to gnome-vfs
Does that help if you use 
char*       gnome_vfs_escape_path_string    (const char *path);
on info->symlink_name ?

RFC 3986 [1] indeed lists the following reserved characters:

      reserved    = gen-delims / sub-delims

      gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

      sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="

So as Christophe already stated, you have to escape these characters before
using them in GnomeVFS.
The relevant gthumb code seems to sit in
libgthumb/file-utils.c:resolve_all_symlinks. Obviously the symlink_name from
GnomeVFSFileInfo is listed unescaped, since it doesn't refer to any URI per se.
I think this should be fixed inside gthumb.

The code

if (first_level && (info->symlink_name[0] != '/'))
  symbolic_link = g_strconcat ("/", info->symlink_name);
else
  symbolic_link = g_strdup (info->symlink_name);

looks odd, since symbolic_link is passed to gnome_vfs_uri_resolve_relative
afterwards. IMHO it should involve gnome_vfs_escape_string.

There seems to have been a lot of work done here, that stopped just short of a patch. Can someone propose and test a patch against CVS HEAD?

- Mike

this should be fixed in svn trunk, can someone test please ?

This is fixed in the development version.

resolve_all_symlinks returns NULL for ssh:// uris. See bug 421019.

- Mike

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

(In reply to comment #15)
> resolve_all_symlinks returns NULL for ssh:// uris. See bug 421019.
> 
> - Mike
> 

should be fixed in svn trunk now.

Confirmed, thanks!

- Mike