[Bug general/4698] Opening up a core file in the source window causes a backtrace

["pmuldoon at redhat dot com" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From pmuldoon at redhat dot com  2007-06-25 15:36 -------
What's happening here is DebugInfo is trying to construct a dwarf representation
of /usr/bin/sleep executable (not sure that is right in a corefile cases), which
is what the core was derived from. If you look in kernel and fcore corefiles, no
pathing information is stored to the arguments data struct, unless the path was
included when the call to run the executable was made.

IE

in the case of:

./sleep 1000 

./sleep is what is recorded in the core file. Of course ./ is pretty useless
after the fact, but that's how corefile's store it.

in the case of 

cd ~/
/usr/bin/sleep 1000 &

/usr/bin/sleep is recorded in the corefile arguments.

As there has been a requirements placed upon corefile code that it automatically
finds its own executable, when corefile's are first instantiated, they go
through this song and dance of trying to find the executable in first: pwd, then
 /bin then /usr/bin. If it cannot find it in those locations, it gives up.

HOWEVER, further calls to proc.getExe() will ONLY return what was in the the
corefile, in this case ./sleep. And that is why this elf/dwarf is failing as it
cannot find ./sleep (should look in /usr/bin/sleep

I'm a bit reluctant to replace getExe() with a reconstructed path, over what was
actually stored in the corefile. Opinions?

-- 


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

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