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

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

[pmuldoon at redhat dot com]

Inside

frysk/frysk-imports/frysk/sys/proc/cni/Exe.cxx

There is a test like:

if (len < 0 || len >= FILENAME_MAX)
    throwErrno (errno, "readlink");

In some situations in the field, getExe() produces garbage. However the above
exception never "surfaces" to the user level, and no indications of an error
happening has occured. If you add in a print statement something like:

if (len < 0 || len >= FILENAME_MAX)
{
    printf("readlink failed on link %s\n",link);
    throwErrno (errno, "readlink");
}

The printf is shown, but no stack trace for the exceptions. This leaves getExe()
always appearing to be correct.

-- 
           Summary: Exe.get() Exceptions are not being thrown
           Product: frysk
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: general
        AssignedTo: frysk-bugzilla at sourceware dot org
        ReportedBy: pmuldoon at redhat dot com


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.

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

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2007-07-12 20:43 -------
This observation happens when a system wide refresh occurs. The easiest way to
replicate this behaviour is to run the UI and open a session. 

-- 


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.

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

[mark at klomp dot org]

------- Additional Comments From mark at klomp dot org  2007-07-12 20:50 -------
Could you include some more information?
Can you change the printf to:

  int eee = errno;
  printf("file: %s, link: %s, len: %d, errno: %d\n", file, link, len, errno);
  errno = eee;

And post what it actually prints out? (Note that you have to safe the errno
value if you are going to reuse it after another system/library call.

Also could you maybe add a #include <java/lang/Thread.h> and
java::lang::Thread::dumpStack(); while you are at it?



-- 


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.

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

[rmoseley at redhat dot com]

------- Additional Comments From rmoseley at redhat dot com  2007-07-13 13:23 -------
Created an attachment (id=1916)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1916&action=view)
screenshot showing garbage characters coming at at the end of the string
returned by getExe


-- 


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.

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

[mark at klomp dot org]

------- Additional Comments From mark at klomp dot org  2007-07-16 10:33 -------
Replaced Exe.get() with standard File.getCanonicalPath():

frysk-core/frysk/proc/live/ChangeLog
2007-07-16  Mark Wielaard  <mwielaard@redhat.com>

    * LinuxProc.java (sendrecExe): Use File.getCanonicalPath().

frysk-imports/frysk/sys/proc/ChangeLog
2007-07-16  Mark Wielaard  <mwielaard@redhat.com>

    * Exe.java: Removed.
    * cni/Exe.cxx: Likewise.

Please report if the problem manifests itself even with this patch applied.

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


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.

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

[cagney at redhat dot com]

------- Additional Comments From cagney at redhat dot com  2007-07-18 02:39 -------
(In reply to comment #4)
> Replaced Exe.get() with standard File.getCanonicalPath():
> 
> frysk-core/frysk/proc/live/ChangeLog
> 2007-07-16  Mark Wielaard  <mwielaard@redhat.com>
> 
>     * LinuxProc.java (sendrecExe): Use File.getCanonicalPath().
> 
> frysk-imports/frysk/sys/proc/ChangeLog
> 2007-07-16  Mark Wielaard  <mwielaard@redhat.com>
> 
>     * Exe.java: Removed.
>     * cni/Exe.cxx: Likewise.
> 
> Please report if the problem manifests itself even with this patch applied.

This isn't the problem.

frysk.sys.proc.Exe.get() returns the _contents_ of the link /proc/$$/exe, while
File.getCanonicalPath() attempts to resolve a chain of links, using something
like repeated stat and readlink(2) calls to determine a final path.  This leads
to Exe.get() returning strings such as "/bin/bash (deleted)", or occasionally,
what appears to be a corrupt string, while getCanonicalPath will throw an
IOException.

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)

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.

The existing frysk.sys.proc.Exe was working as designed.

-- 


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.

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

[mark at klomp dot 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.