Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

ArithmeticException: / by zero

See original GitHub issue

I’m running into an exception during analysis with ghidra 9.1:

java.lang.ArithmeticException: / by zero
	at ghidra.program.util.ProgramMemoryUtil.findBytePattern(ProgramMemoryUtil.java:653)
	at ghidra.program.util.ProgramMemoryUtil.findImageBaseOffsets32(ProgramMemoryUtil.java:615)
	at ghidra.app.plugin.prototype.CppCodeAnalyzerPlugin.wrappers.RttiModelWrapper.getRtti3Model(RttiModelWrapper.java:187)
	at ghidra.app.plugin.prototype.CppCodeAnalyzerPlugin.wrappers.RttiModelWrapper.<init>(RttiModelWrapper.java:126)
	at ghidra.app.plugin.prototype.CppCodeAnalyzerPlugin.wrappers.RttiModelWrapper.getWrapper(RttiModelWrapper.java:115)
	at ghidra.app.plugin.prototype.CppCodeAnalyzerPlugin.windows.WindowsCppClassAnalyzer.getClassTypeInfoList(WindowsCppClassAnalyzer.java:97)
	at ghidra.app.plugin.prototype.CppCodeAnalyzerPlugin.windows.WindowsCppClassAnalyzer.getClassTypeInfoList(WindowsCppClassAnalyzer.java:115)
	at ghidra.app.plugin.prototype.CppCodeAnalyzerPlugin.AbstractCppClassAnalyzer.added(AbstractCppClassAnalyzer.java:98)
	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: /nix/store/y800x6fvshyj0qb5bdk5adc8d8cgfprq-openjdk-11.0.6-ga/lib/openjdk
JVM Version: Oracle Corporation 11.0.6-internal
OS: Linux 4.19.80 amd64
Workstation: nixos

Issue Analytics

State:
Created 4 years ago
Comments:5 (3 by maintainers)

Top GitHub Comments

1reaction

astrelskycommented, Feb 20, 2020

I think it’s the 0 on that same line: this is the alignment field, and it’s ultimately used in a division here: https://github.com/NationalSecurityAgency/ghidra/blob/024a6190e0ae76c788d0ce6f3c8b161d2f52f8d1/Ghidra/Features/Base/src/main/java/ghidra/program/util/ProgramMemoryUtil.java#L697

In fact, I changed this line to 4 and analysis works fine. I don’t know what the “right” value for alignment is in the general case, though.

Thank you for looking into it. I was under the impression that passing 0 would disable alignment checking. Since this was not the case I set it to the alignment value of the datatype. It is usually 4 but it’s best to get the value from the program’s ImageBaseOffset32DataType just in case.

0reactions

tomsmalleycommented, Feb 20, 2020

I think it’s the 0 on that same line: this is the alignment field, and it’s ultimately used in a division here: https://github.com/NationalSecurityAgency/ghidra/blob/024a6190e0ae76c788d0ce6f3c8b161d2f52f8d1/Ghidra/Features/Base/src/main/java/ghidra/program/util/ProgramMemoryUtil.java#L697

In fact, I changed this line to 4 and analysis works fine. I don’t know what the “right” value for alignment is in the general case, though.