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

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

[pmuldoon at redhat dot com]

[pmuldoon@localhost frysk-core]$ sleep 1000 &
[1] 5924

[pmuldoon@localhost frysk-core]$ ./frysk/bindir/fcore 5924

[pmuldoon@localhost frysk_bin]$ ./frysk-core/frysk/bindir/fstack ~/core.5924 
Task #5924
#0 0x00705402 in __kernel_vsyscall ()
#1 0x4daf7c90 in __GI___libc_nanosleep ()
#2 0x10094bf1 in [unknown]
#3 0x10091d9a in [unknown]
#4 0x4da7ff2c in __libc_start_main ()
#5 0x08048bd1 in [unknown]

and the live process trace:

[pmuldoon@localhost frysk_bin]$ ./frysk-core/frysk/bindir/fstack 5924
Task #5924
#0 0x00705402 in __kernel_vsyscall ()
#1 0x4daf7c90 in __GI___libc_nanosleep ()
#2 0x10094bf1 in [unknown]
#3 0x10091d9a in [unknown]
#4 0x4da7ff2c in __libc_start_main ()
#5 0x08048bd1 in [unknown]

But when opening up that corefile in the source window I get:

java.lang.NullPointerException
   at lib.dw.DwarfDie.getDecl(FryskGui)
   at frysk.debuginfo.DebugInfo.setSubprogram(FryskGui)
   at frysk.debuginfo.DebugInfo.setFrames(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.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)

-- 
           Summary: Opening up a core file in the source window causes a
                    backtrace
           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=4698

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

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

[swagiaal at redhat dot com]

------- 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.

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

[pmuldoon at redhat dot com]

------- 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.

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

[swagiaal at redhat dot com]

------- 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.

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

[pmuldoon at redhat dot com]

------- 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.

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

[pmuldoon at redhat dot com]

------- 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.

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

[npremji at redhat dot com]

------- 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.