* [Bug general/4788] Exe.get() Exceptions are not being thrown
2007-07-12 20:34 [Bug general/4788] New: Exe.get() Exceptions are not being thrown pmuldoon at redhat dot com
@ 2007-07-12 20:43 ` pmuldoon at redhat dot com
2007-07-12 20:50 ` mark at klomp dot org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pmuldoon at redhat dot com @ 2007-07-12 20:43 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug general/4788] Exe.get() Exceptions are not being thrown
2007-07-12 20:34 [Bug general/4788] New: Exe.get() Exceptions are not being thrown pmuldoon at redhat dot com
2007-07-12 20:43 ` [Bug general/4788] " pmuldoon at redhat dot com
@ 2007-07-12 20:50 ` mark at klomp dot org
2007-07-13 13:23 ` rmoseley at redhat dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: mark at klomp dot org @ 2007-07-12 20:50 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug general/4788] Exe.get() Exceptions are not being thrown
2007-07-12 20:34 [Bug general/4788] New: Exe.get() Exceptions are not being thrown pmuldoon at redhat dot com
2007-07-12 20:43 ` [Bug general/4788] " pmuldoon at redhat dot com
2007-07-12 20:50 ` mark at klomp dot org
@ 2007-07-13 13:23 ` rmoseley at redhat dot com
2007-07-16 10:34 ` mark at klomp dot org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rmoseley at redhat dot com @ 2007-07-13 13:23 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug general/4788] Exe.get() Exceptions are not being thrown
2007-07-12 20:34 [Bug general/4788] New: Exe.get() Exceptions are not being thrown pmuldoon at redhat dot com
` (2 preceding siblings ...)
2007-07-13 13:23 ` rmoseley at redhat dot com
@ 2007-07-16 10:34 ` mark at klomp dot org
2007-07-18 2:40 ` cagney at redhat dot com
2007-07-18 8:15 ` mark at klomp dot org
5 siblings, 0 replies; 7+ messages in thread
From: mark at klomp dot org @ 2007-07-16 10:34 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug general/4788] Exe.get() Exceptions are not being thrown
2007-07-12 20:34 [Bug general/4788] New: Exe.get() Exceptions are not being thrown pmuldoon at redhat dot com
` (3 preceding siblings ...)
2007-07-16 10:34 ` mark at klomp dot org
@ 2007-07-18 2:40 ` cagney at redhat dot com
2007-07-18 8:15 ` mark at klomp dot org
5 siblings, 0 replies; 7+ messages in thread
From: cagney at redhat dot com @ 2007-07-18 2:40 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug general/4788] Exe.get() Exceptions are not being thrown
2007-07-12 20:34 [Bug general/4788] New: Exe.get() Exceptions are not being thrown pmuldoon at redhat dot com
` (4 preceding siblings ...)
2007-07-18 2:40 ` cagney at redhat dot com
@ 2007-07-18 8:15 ` mark at klomp dot org
5 siblings, 0 replies; 7+ messages in thread
From: mark at klomp dot org @ 2007-07-18 8:15 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread