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 159884 - problems resolving relative symlinks with reserved URI characters
problems resolving relative symlinks with reserved URI characters
Status: RESOLVED FIXED
Product: gthumb
Classification: Other
Component: general
2.6.x
Other All
: High critical
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
: 159885 421019 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-11-29 19:20 UTC by Thomas M.
Modified: 2007-03-22 12:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas M. 2004-11-29 19:20:44 UTC
Distribution: Debian 3.1
Package: gthumb
Severity: normal
Version:  2.6.0.1
Synopsis: Crash while changing directory
Bugzilla-Product: gthumb
Bugzilla-Component: general
Bugzilla-Version: 2.6.0.1
BugBuddy-GnomeVersion: 2.0 (2.8.0)
Description:
Description of the crash:

I was browsing my photo collection with gthumb.
Gthumb crashed (backtrace attached) when I opened a directory (which
happened to have lost of files, more than 500) .



Debugging Information:

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

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
`system-supplied DSO at 0xffffe000' has disappeared; keeping its
symbols.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208677984 (LWP 24526)]
[New Thread -1263613008 (LWP 24533)]
[Thread debugging using libthread_db enabled]
[New Thread -1208677984 (LWP 24526)]
[New Thread -1263613008 (LWP 24533)]
[New Thread -1254536272 (LWP 24532)]
[New Thread -1246143568 (LWP 24531)]
[New Thread -1237750864 (LWP 24530)]
[New Thread -1229358160 (LWP 24529)]
[New Thread -1220613200 (LWP 24528)]
[New Thread -1211638864 (LWP 24527)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()

Thread 1 (Thread -1208677984 (LWP 24526))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 libgnomeui_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #3 <signal handler called>
  • #4 gnome_vfs_uri_to_string
    from /usr/lib/libgnomevfs-2.so.0
  • #5 new_path_from_uri
    from /usr/lib/libgthumb.so
  • #6 resolve_all_symlinks
    from /usr/lib/libgthumb.so
  • #7 comments_get_comment_filename
    from /usr/lib/libgthumb.so
  • #8 comments_load_comment
    from /usr/lib/libgthumb.so
  • #9 file_data_update_comment
    from /usr/lib/libgthumb.so
  • #10 gth_file_list_interrupt_set_list
    from /usr/lib/libgthumb.so
  • #11 _gnome_vfs_job_complete
    from /usr/lib/libgnomevfs-2.so.0
  • #12 _gnome_vfs_job_complete
    from /usr/lib/libgnomevfs-2.so.0
  • #13 g_child_watch_add
    from /usr/lib/libglib-2.0.so.0
  • #14 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #15 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #16 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #17 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #18 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #19 main
  • #0 __kernel_vsyscall




------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-11-29 14:20 -------


Unknown version 2.6.0.1 in product gthumb.  Setting version to "unspecified".
Unknown platform unknown. Setting to default platform "Other".
Unknown milestone "unknown" in product "gthumb".
   Setting to default milestone for this product, '---'
Setting to default status "UNCONFIRMED".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Elijah Newren 2004-11-29 19:27:20 UTC
Appears to be a unique stack trace, according to the simple-dup-finder.
Comment 2 Elijah Newren 2004-11-29 19:36:24 UTC
*** Bug 159885 has been marked as a duplicate of this bug. ***
Comment 3 Thomas M. 2004-12-02 18:59:00 UTC
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.
Comment 4 Thomas M. 2004-12-02 19:23:47 UTC
Here is a proper backtrace :

Program received signal SIGSEGV, Segmentation fault.

Thread NaN (LWP 22760)

  • #0 gnome_vfs_uri_to_string
    from /usr/lib/libgnomevfs-2.so.0
  • #1 new_path_from_uri
    from /usr/lib/libgthumb.so
  • #2 resolve_all_symlinks
    from /usr/lib/libgthumb.so
  • #3 comments_get_comment_filename
    from /usr/lib/libgthumb.so
  • #4 comments_load_comment
    from /usr/lib/libgthumb.so
  • #5 file_data_update_comment
    from /usr/lib/libgthumb.so
  • #6 gth_file_list_interrupt_set_list
    from /usr/lib/libgthumb.so
  • #7 _gnome_vfs_job_complete
    from /usr/lib/libgnomevfs-2.so.0
  • #8 _gnome_vfs_job_complete
    from /usr/lib/libgnomevfs-2.so.0
  • #9 g_child_watch_add
    from /usr/lib/libglib-2.0.so.0
  • #10 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #11 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #12 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #13 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #14 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #15 main

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.

Comment 5 Thomas M. 2004-12-02 20:27:42 UTC
I recompiled libgnomevfs with debug enabled :

(gdb) bt
  • #0 gnome_vfs_uri_to_string
    at gnome-vfs-uri.c line 1108
  • #1 new_path_from_uri
    from /usr/lib/libgthumb.so
  • #2 resolve_all_symlinks
    from /usr/lib/libgthumb.so
  • #3 comments_get_comment_filename
    from /usr/lib/libgthumb.so
  • #4 comments_load_comment
    from /usr/lib/libgthumb.so
  • #5 file_data_update_comment
    from /usr/lib/libgthumb.so
  • #6 gth_file_list_interrupt_set_list
    from /usr/lib/libgthumb.so
  • #7 dispatch_get_file_info_callback
    at gnome-vfs-job.c line 247
  • #8 dispatch_job_callback
    at gnome-vfs-job.c line 559
  • #9 g_child_watch_add
    from /usr/lib/libglib-2.0.so.0
  • #10 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #11 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #12 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #13 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #14 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #15 main

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 ??
Comment 6 Thomas M. 2004-12-02 20:39:48 UTC
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 ?



Comment 7 Thomas M. 2004-12-03 18:33:24 UTC
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).
Comment 8 Thomas M. 2004-12-03 19:08:02 UTC
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 ???


Comment 9 Thomas M. 2004-12-06 07:15:05 UTC
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 '/'.
Comment 10 Christophe Fergeau 2005-01-09 11:37:20 UTC
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 ?
Comment 11 Christian Neumair 2005-05-06 19:28:17 UTC
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.
Comment 12 Michael Chudobiak 2006-10-19 12:55:13 UTC
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
Comment 13 Paolo Bacchilega 2007-03-08 15:37:07 UTC
this should be fixed in svn trunk, can someone test please ?
Comment 14 Paolo Bacchilega 2007-03-09 20:55:12 UTC
This is fixed in the development version.
Comment 15 Michael Chudobiak 2007-03-21 14:04:06 UTC
resolve_all_symlinks returns NULL for ssh:// uris. See bug 421019.

- Mike
Comment 16 Michael Chudobiak 2007-03-21 14:04:26 UTC
*** Bug 421019 has been marked as a duplicate of this bug. ***
Comment 17 Paolo Bacchilega 2007-03-21 23:41:11 UTC
(In reply to comment #15)
> resolve_all_symlinks returns NULL for ssh:// uris. See bug 421019.
> 
> - Mike
> 

should be fixed in svn trunk now.
Comment 18 Michael Chudobiak 2007-03-22 12:20:39 UTC
Confirmed, thanks!

- Mike