Bug 3677

Summary:	NPE's when source window is started with johntheripper on x86_64 dual cpu/FC6
Product:	frysk	Reporter:	Rick Moseley <rmoseley>
Component:	general	Assignee:	Tim Moore <moore>
Status:	RESOLVED FIXED
Severity:	normal	CC:	cagney, rmoseley, timoore
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:
Project(s) to access:		ssh public key:
Bug Depends on:
Bug Blocks:	1633

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.