This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/417: GDB crashes when source path has few links
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 14 Mar 2002 17:58:06 -0000
- Subject: Re: gdb/417: GDB crashes when source path has few links
- Reply-to: Andrew Cagney <ac131313 at cygnus dot com>
The following reply was made to PR gdb/417; it has been noted by GNATS.
From: Andrew Cagney <ac131313@cygnus.com>
To: veksler@il.ibm.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/417: GDB crashes when source path has few links
Date: Thu, 14 Mar 2002 11:48:33 -0500
(ulgh, two different bug reports against the same 3 line patch :-).
> Sometimes gdb crashes when it tries to display sources.
>
> open_source_file() calls openp() which assumes that if open() succeeds so does canonicalize_file_name(). After openp() succeeded to open the file, open_source_file() assumes that it has a canonic file name. But this assumption is incorrect.
>
> Here is why success of open_source_file() and open() is not related:
> Linux limits recursive symlinks to 5 (a->b->c->d->e).
> Linux-2.2 does not limit num of consecutive sym-links.
> Linux-2.4 the limit for consecutive links is 40.
>
> On the other hand, glibc's canonicalize_file_name limits all kinds of symlinks (consecutive and recursive)to MAXSYMLINKS (it's 5 in glibc-2.2, and is 20 in glibc-2.2.4).
>
> This means that in glibc-2.2.4 it is possible to have open fail on a->b->c->d->e->f, and get canonicalize_file_name() to succeed.
> This also means that in glibc-2.2 for "mkdir t ; cd t ; ln -s ../t", open("t/t/t/t/t/t/t/t") succeeds while canonicalize_file_name fails.
Does modifying utils.c to use realpath() instead of
canonicalize_file_name() provide a tempoary work around to the problem?
(I suspect not but might be worth a try).
(NB: need to also check that canonicalize_file_name() allocates space
from the heap.)