* [Bug general/4698] Opening up a core file in the source window causes a backtrace
2007-06-25 13:43 [Bug general/4698] New: Opening up a core file in the source window causes a backtrace pmuldoon at redhat dot com
@ 2007-06-25 15:11 ` swagiaal at redhat dot com
2007-06-25 15:36 ` pmuldoon at redhat dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: swagiaal at redhat dot com @ 2007-06-25 15:11 UTC (permalink / raw)
To: frysk-bugzilla
------- Additional Comments From swagiaal at redhat dot com 2007-06-25 15:11 -------
Phil, sounds like your hunch was right; looks like this is caused by failure to
create a dwarf object:
I added a throw exception in the constructor:
Index: frysk-core/frysk/debuginfo/DebugInfo.java
===================================================================
RCS file: /cvs/frysk/frysk-core/frysk/debuginfo/DebugInfo.java,v
retrieving revision 1.10
diff -u -r1.10 DebugInfo.java
--- frysk-core/frysk/debuginfo/DebugInfo.java 14 Jun 2007 03:20:33 -0000 1.10
+++ frysk-core/frysk/debuginfo/DebugInfo.java 25 Jun 2007 15:09:53 -0000
@@ -94,7 +94,9 @@
dwarf = new Dwarf(elf, DwarfCommand.READ, null);
}
catch (lib.elf.ElfException ignore)
- {}
+ {
+ throw new RuntimeException(ignore);
+ }
debugInfoEvaluator = new DebugInfoEvaluator[1];
subprogram = new Subprogram[1];
debugInfoEvaluator[0] = new DebugInfoEvaluator (frame);
and got the following:
java.lang.RuntimeException: lib.elf.ElfFileException: Could not open sleep
at frysk.debuginfo.DebugInfo.<init>(FryskGui)
at frysk.gui.srcwin.SourceWindow.generateProcStackTrace(FryskGui)
at frysk.gui.srcwin.SourceWindow.finishSourceWin(FryskGui)
at frysk.gui.srcwin.SourceWindow.<init>(FryskGui)
at frysk.gui.srcwin.SourceWindowFactory.createSourceWindow(FryskGui)
at frysk.gui.srcwin.SourceWindowFactory.attachToCore(FryskGui)
at frysk.gui.srcwin.SourceWindow.examineCoreFile(FryskGui)
at frysk.gui.srcwin.SourceWindow$2.actionEvent(FryskGui)
at org.gnu.gtk.Action.fireActionEvent(libgtkjava-2.10.so)
at org.gnu.gtk.Action.handleActivate(libgtkjava-2.10.so)
Caused by: lib.elf.ElfFileException: Could not open sleep
at lib.elf.Elf.elf_begin(FryskGui)
at lib.elf.Elf.<init>(FryskGui)
at frysk.debuginfo.DebugInfo.<init>(FryskGui)
...9 more
--
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug general/4698] Opening up a core file in the source window causes a backtrace
2007-06-25 13:43 [Bug general/4698] New: Opening up a core file in the source window causes a backtrace pmuldoon at redhat dot com
2007-06-25 15:11 ` [Bug general/4698] " swagiaal at redhat dot com
@ 2007-06-25 15:36 ` pmuldoon at redhat dot com
2007-06-25 15:59 ` swagiaal at redhat dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pmuldoon at redhat dot com @ 2007-06-25 15:36 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug general/4698] Opening up a core file in the source window causes a backtrace
2007-06-25 13:43 [Bug general/4698] New: Opening up a core file in the source window causes a backtrace pmuldoon at redhat dot com
2007-06-25 15:11 ` [Bug general/4698] " swagiaal at redhat dot com
2007-06-25 15:36 ` pmuldoon at redhat dot com
@ 2007-06-25 15:59 ` swagiaal at redhat dot com
2007-06-25 16:08 ` pmuldoon at redhat dot com
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: swagiaal at redhat dot com @ 2007-06-25 15:59 UTC (permalink / raw)
To: frysk-bugzilla
------- Additional Comments From swagiaal at redhat dot com 2007-06-25 15:59 -------
Are core files meant to be self containted ?
If so then this is a bad core file. Why is the executable needed ?
If not then there is no safe way to figure out what the executable that was used
to create the is, in which case the user should specify it.
So two sides to this:
fcore should make sure the information is correctly retrieved, failing that
frysk should be able to handle a case where the executable is unknown
--
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug general/4698] Opening up a core file in the source window causes a backtrace
2007-06-25 13:43 [Bug general/4698] New: Opening up a core file in the source window causes a backtrace pmuldoon at redhat dot com
` (2 preceding siblings ...)
2007-06-25 15:59 ` swagiaal at redhat dot com
@ 2007-06-25 16:08 ` pmuldoon at redhat dot com
2007-06-25 18:31 ` pmuldoon at redhat dot com
2007-06-25 19:33 ` npremji at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: pmuldoon at redhat dot com @ 2007-06-25 16:08 UTC (permalink / raw)
To: frysk-bugzilla
------- Additional Comments From pmuldoon at redhat dot com 2007-06-25 16:08 -------
(In reply to comment #3)
> Are core files meant to be self containted ?\
Depends what you mean. Corefiles are not complete snapshots of an executable
when it was running. Some segments are elided (not written) as they can be
recreated later from looking at the linkmap table, and whether that segment has
been written to, and reconstructing the metadata/maps from parsing each and
every included solib in the linkmap table, looking for PT_LOAD headers. It does
this now.
> If so then this is a bad core file. Why is the executable needed ?
To look at non elided segments (ie actually in the corefile), process data,
thread data , auxv data) no executbale is needed. To read and reconstruct from
elided segments, do backtraces the executable's .dynamic, .interp segments are
needed.
> If not then there is no safe way to figure out what the executable that was used
That's the user specifiying the executable path is the safest
> to create the is, in which case the user should specify it.
Agree, but there is a requirement that corefiles locat it themselves.
> So two sides to this:
> fcore should make sure the information is correctly retrieved, failing that
fcore can only put into the corefile the information it is provided via Proc.
That is the infromation provided. This is the same information the kernel
provides for its corefiles, so the reference implementation is correct.
> frysk should be able to handle a case where the executable is unknown
It does, normally. This is part bug on my side, too. The corefile found it's
excutabke in the beginning /usr/bin/sleep, but when asked what it's executable
is, it reported ./sleep which is what is stored in the core file.
--
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug general/4698] Opening up a core file in the source window causes a backtrace
2007-06-25 13:43 [Bug general/4698] New: Opening up a core file in the source window causes a backtrace pmuldoon at redhat dot com
` (3 preceding siblings ...)
2007-06-25 16:08 ` pmuldoon at redhat dot com
@ 2007-06-25 18:31 ` pmuldoon at redhat dot com
2007-06-25 19:33 ` npremji at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: pmuldoon at redhat dot com @ 2007-06-25 18:31 UTC (permalink / raw)
To: frysk-bugzilla
------- Additional Comments From pmuldoon at redhat dot com 2007-06-25 18:31 -------
2007-06-25 Phil Muldoon <pmuldoon@redhat.com>
* LinuxProc.java (sendrecExe): If a constructed filename
is available, use that instead of args[0].
Fixed the exectuable issue. Now when the source window is run with a corefile
(that can find it's executable) this code:
/* Attach the variableWatchView to the WatchList for this process */
getCurrentDebugProcess().getWatchList().addListener(watchView);
triggers the following backtrace to happen. Commenting out this code brings up
the source window, with the stacktrace and source for the core file though.
stacktrace:
java.lang.NullPointerException
at frysk.gui.srcwin.SourceWindow.finishSourceWin(FryskGui)
at frysk.gui.srcwin.SourceWindow.<init>(FryskGui)
at frysk.gui.srcwin.SourceWindowFactory.createSourceWindow(FryskGui)
at frysk.gui.srcwin.SourceWindowFactory.attachToCore(FryskGui)
at frysk.gui.srcwin.SourceWindow.examineCoreFile(FryskGui)
at frysk.gui.srcwin.SourceWindow$2$4.fileActivated(FryskGui)
at org.gnu.gtk.FileChooserHelper.fireFileActivated(libgtkjava-2.8.so)
at org.gnu.gtk.FileChooserDialog.handleFileActivated(libgtkjava-2.8.so)
at org.gnu.gtk.Dialog.gtk_dialog_run(libgtkjava-2.8.so)
at org.gnu.gtk.Dialog.run(libgtkjava-2.8.so)
at org.gnu.gtk.FileChooserDialog.open(libgtkjava-2.8.so)
at frysk.gui.srcwin.SourceWindow$2.actionEvent(FryskGui)
at org.gnu.gtk.Action.fireActionEvent(libgtkjava-2.8.so)
at org.gnu.gtk.Action.handleActivate(libgtkjava-2.8.so)
at org.gnu.gtk.Gtk.gtk_main(libgtkjava-2.8.so)
at org.gnu.gtk.Gtk.main(libgtkjava-2.8.so)
at frysk.gui.Gui.gui(FryskGui)
at frysk.gui.FryskGui.main(FryskGui)
--
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug general/4698] Opening up a core file in the source window causes a backtrace
2007-06-25 13:43 [Bug general/4698] New: Opening up a core file in the source window causes a backtrace pmuldoon at redhat dot com
` (4 preceding siblings ...)
2007-06-25 18:31 ` pmuldoon at redhat dot com
@ 2007-06-25 19:33 ` npremji at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: npremji at redhat dot com @ 2007-06-25 19:33 UTC (permalink / raw)
To: frysk-bugzilla
------- Additional Comments From npremji at redhat dot com 2007-06-25 19:33 -------
fixed last problem:
frysk-core/frysk/gui/srcwin/CL
* SourceWindow.java (getCurrentDebugProcess): Added logging message.
(finishSourceWindow): Don't add a variable watch if no DebugProcess exists
for this SourceWindow.
--
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.
^ permalink raw reply [flat|nested] 7+ messages in thread