Bug 3677 - NPE's when source window is started with johntheripper on x86_64 dual cpu/FC6
Summary: NPE's when source window is started with johntheripper on x86_64 dual cpu/FC6
Status: RESOLVED FIXED
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Tim Moore
URL:
Keywords:
Depends on:
Blocks: 1633
  Show dependency tree / graph
 
Reported: 2006-12-07 16:39 UTC by Rick Moseley
Modified: 2007-08-01 19:25 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Moseley 2006-12-07 16:39:33 UTC 
After building johntheripper with the "linux-x86-64-mmx" option and then trying
to bring it up in the source window NPE's are generated almost perpetually.  The
machine is an x86_64 dual cpu machine running FC6.  This was done with a fresh
checkout of Frysk on the morning of 07-12-2006.  Here is the NPE:

java.lang.NullPointerException
   at frysk.gui.srcwin.CurrentStackView.buildTree(CurrentStackView.java:152)
   at frysk.gui.srcwin.CurrentStackView.<init>(CurrentStackView.java:102)
   at frysk.gui.srcwin.SourceWindow.populateStackBrowser(SourceWindow.java:370)
   at frysk.gui.srcwin.SourceWindow.finishSourceWin(SourceWindow.java:319)
   at frysk.gui.srcwin.SourceWindow$LockObserver$25.run(SourceWindow.java:2196)
   at org.gnu.glib.CustomEvents.runEvents(libgtkjava-2.8.so)
   at org.gnu.gtk.Gtk.gtk_main(libgtkjava-2.8.so)

This behaviour does not occur on my x86 single cpu with a fresh frysk checkout
running FC5.  The window comes up but says there is no debug info available.
Comment 1 Mike Cvet 2006-12-07 18:28:01 UTC 
I've narrowed this down to null StackFrames coming in to the function, which 
shouldn't happen. This is bad news because the reason they are null is as 
follows:

Error generating stack trace
null
java.lang.NullPointerException
   at frysk.rt.StackCallbacks.accessReg(FryskGui)
   at lib.unwind.StackTraceCreator.unwind_setup(FryskGui)
   at lib.unwind.StackTraceCreator.createStackTrace(FryskGui)
   at frysk.rt.StackFactory.createStackFrame(FryskGui)
   at frysk.rt.StackFactory.createStackFrame(FryskGui)
   at frysk.gui.srcwin.SourceWindow.generateProcStackTrace(FryskGui)
   at frysk.gui.srcwin.SourceWindow.finishSourceWin(FryskGui)
   at frysk.gui.srcwin.SourceWindow$LockObserver$25.run(FryskGui)   at 
org.gnu.glib.CustomEvents.runEvents(libgtkjava-2.8.so)
   at org.gnu.gtk.Gtk.gtk_main(libgtkjava-2.8.so)
   at frysk.gui.Gui.gui(FryskGui)
   at frysk.gui.FryskGui.main(FryskGui)
Comment 2 Rick Moseley 2006-12-07 18:31:04 UTC 
Added blocker.
Comment 3 Mike Cvet 2006-12-07 19:16:39 UTC 
Once again, the program is looking for register 'st5' in accessReg. The line:

long value = isa.getRegisterByName(registerName).get(myTask);

blows up because isa.getRegisterByName("st5") returns null.
Comment 4 Mike Cvet 2006-12-07 22:03:53 UTC 
So what's going on here is that there is no "st" series register in 
LinuxIa32On64.java, and that is where Frysk is looking for the register, since 
the build target "linux-x86-64-mmx" is actually building for i386 + mmx 
registers, and Rick built this on a 64-bit system.

Looks like these just need to be added to that class.
Comment 5 Mike Cvet 2006-12-13 19:39:49 UTC 
I've verified that Tim's latest patches to linuxIa32On64 fix this problem - re-
assigning to Tim to close this bug.
Comment 6 Mike Cvet 2007-02-20 18:51:42 UTC 
ping?
Comment 7 Mike Cvet 2007-08-01 19:25:38 UTC 
Fixed by Tim ages ago.