Commit 67744fb cause errors in auto analysis
Closed this issue · 6 comments
Looks like I'm encountering a few errors loading my binary:
The first two are NullPointerExceptions
Analysis Task: Data Reference -
java.lang.NullPointerException
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:760)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:612)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:605)
at ghidra.app.util.PseudoDisassembler.isValidSubroutine(PseudoDisassembler.java:366)
at ghidra.app.plugin.core.analysis.OperandReferenceAnalyzer.added(OperandReferenceAnalyzer.java:458)
at ghidra.app.plugin.core.analysis.AnalysisScheduler.runAnalyzer(AnalysisScheduler.java:185)
at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:39)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:685)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:785)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:664)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:629)
at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:62)
at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:101)
at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
at java.base/java.lang.Thread.run(Thread.java:834)
Build Date: 2019-Oct-23 1737 EDT
Ghidra Version: 9.1
Java Home: C:\Program Files\Java\jdk-11.0.2
JVM Version: Oracle Corporation 11.0.2
OS: Windows 10 10.0 amd64
Workstation: DESKTOP-GHRIIHN
Analysis Task: Reference -
java.lang.NullPointerException
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:760)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:612)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:605)
at ghidra.app.util.PseudoDisassembler.isValidSubroutine(PseudoDisassembler.java:366)
at ghidra.app.plugin.core.analysis.OperandReferenceAnalyzer.added(OperandReferenceAnalyzer.java:458)
at ghidra.app.plugin.core.analysis.AnalysisScheduler.runAnalyzer(AnalysisScheduler.java:185)
at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:39)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:685)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:785)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:664)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:629)
at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:62)
at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:101)
at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
at java.base/java.lang.Thread.run(Thread.java:834)
Build Date: 2019-Oct-23 1737 EDT
Ghidra Version: 9.1
Java Home: C:\Program Files\Java\jdk-11.0.2
JVM Version: Oracle Corporation 11.0.2
OS: Windows 10 10.0 amd64
Workstation: DESKTOP-GHRIIHN
Followed by an Analysis Task error:
Analysis Task: Create Address Tables - One Time -
java.lang.NullPointerException
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:760)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:612)
at ghidra.app.util.PseudoDisassembler.isValidCode(PseudoDisassembler.java:399)
at ghidra.app.plugin.core.disassembler.AddressTable.getFunctionEntries(AddressTable.java:759)
at ghidra.app.plugin.core.disassembler.AddressTableAnalyzer.added(AddressTableAnalyzer.java:195)
at ghidra.app.plugin.core.analysis.OneShotAnalysisCommand.applyTo(OneShotAnalysisCommand.java:47)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:685)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:785)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:664)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:629)
at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:62)
at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:101)
at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
at java.base/java.lang.Thread.run(Thread.java:834)
Build Date: 2019-Oct-23 1737 EDT
Ghidra Version: 9.1
Java Home: C:\Program Files\Java\jdk-11.0.2
JVM Version: Oracle Corporation 11.0.2
OS: Windows 10 10.0 amd64
Workstation: DESKTOP-GHRIIHN
I feel as though the information produced by these errors won't be very helpful, so I will go back to each commit and reload the binary to see exactly when things broke
EDIT: Can confirm commit 67744fb broke auto-analysis.
I did make a lot of changes recently (trying to cleanup things and add some niceties for the disassembly and better PCODE for decompiler). I think I got these too, but wrote it off to mismatches in the binary I was looking at from all the reloading of ghidra I was doing during dev, thanks for verifying it is broken.
I think I made a mistake on the effective addressing and its probably trying to deref something that isn't there (though surprising that ghidra cares as loudly as it is).
You mind sharing your binary, or know of any repos that have some binaries (w/ tips on loading)?
I found an old prebuilt version of gcc/binutils and was able to eventually build the ghidra testing code, but there are issues there ATM (mostly related to COFF).
I don't have a binary I think I can share here as it may constitute piracy, but I can reference this here: https://github.com/mamedev/mame/blob/f852af6cb8de67eb8abab8f3d5c517b576fbc2f9/src/mame/drivers/model2.cpp#L4386 which is the binary data I am using. If you can find this file online, the two referenced files are word interleaved, meaning 2 bytes from file 1, then two bytes from file 2. Combine the two referenced files and you have the binary I am using.
As for repos that have some binaries, you might want to check out DrItanium's i960 research here: https://github.com/DrItanium/i960
They also created prebuild GCCs specifically targeting the i960 on archive.org:
ELF - https://archive.org/details/i960-elf-gcc-3.4.6.tar
COFF - https://archive.org/details/i960-coff-gcc-3.4.6.tar
I contributed the NINDY source code to him here, as I personally own the debugging unit: https://github.com/DrItanium/i960/tree/master/src/DISK1-NINDY
If you can compile it, I suggest using CTOOLS as a main compiler (labeled as gnu960 but it's actually CTOOLS 5.0 for unix): https://github.com/DrItanium/i960/tree/master/src/gnu960
Another binary you might look at is an old copy of uClinux by @kmaslack, https://web.archive.org/web/20010812190449/http://www.cse.ogi.edu/~kma/uClinux.html
With enough digging, you could probably get the original source to compare it as well.
thanks for all the links, super helpful. Got your interleaved binary loaded (with that commit reverted).
I think c7d59ea fixes the big issues with the bad commit. There is still something funky going on with stack analysis. Will need to add some java to fix it looks like at this point.
I can confirm on my end that the errors for this issue have been resolved. While there may still be more work to do, at least auto analysis does not crash, so I'm going to go ahead and close the issue.