Re: gdb/417: GDB crashes when source path has few links

[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.)