[Bug general/4788] Exe.get() Exceptions are not being thrown

["mark at klomp dot org" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From mark at klomp dot org  2007-07-18 08:15 -------
Hi Andrew,

(In reply to comment #5)
> The apparently corrupt string is caused by a kernel "feature" where it is trying
> to track the executable as it is renamed.  The "feature" can lead to some
> strange sequences.  vis, how things should work:
> 
> $ cp /bin/bash /tmp
> $ mkdir /tmp/x
> $ /tmp/bash
> bash$ mv /tmp/bash /tmp/x
> bash$ ls -l /proc/$$/exe
>  -> /tmp/x/bash
> 
> and when something is deleted:
> 
> $ cp /bin/bash /tmp
> $ /tmp/bash
> bash$ rm /tmp/bash
> bash$ ls -l /proc/$$/exe
>   -> /bin/bash (deleted)

Yes, in both cases you would get a reference to a non-existing file. The code
should return null if the link cannot be followed and the caller should check if
they get a real file or not before proceeding.

> how things get confused:
> 
> $ cp /bin/bash /tmp
> $ cp /bin/bash /tmp/a-really-long-file
> $ /bin/bash
> bash$ mv /tmp/a-really-long-file /tmp/bash
> bash$ ls -l /proc/$$/exe
>   -> /bin/bash
> 
> a dump of the contents of the link shows it in fact contains something like:
>     /bin/bash^@lly-long-file (deleted)
> and this will occur after pre-link as been run.

I couldn't easily replicate this with the above example, but this would explain
why garbage was returned from the old code if really long file names/paths were
used. It was using readlink in a wrong way by just allocating huge static
buffers on the stack instead of calling readlink as recommended by the glibc manual:
http://www.gnu.org/software/libc/manual/html_node/Symbolic-Links.html

Cheers,

Mark

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=4788

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.