GDB: Error with the command disassemble after manually breaking from the target

Describe the bug I use a target GDB stub that allows to manually break which allows GDB to gain control back. The stub seems to behave properly by sending a correct stop reply response, GDB does gain back control and Ghidra sees everything as if I just broke manually, but it displays an error that a NullPointerException happened while processing the command disassemble.

To Reproduce Steps to reproduce the behavior:

1. This bug was reproduced with the mgba’s GDB stub, a GameBoy Advance emulator. I wrote a guide on setting this up on a Linux machine which you can follow here: https://gist.github.com/aldelaro5/d532b21b5e2ec48d5f78e81846c1c1b7 I would mostly do the static analysis and debugging section, you at least need to have a GDB connexion going, have your static listing open after first analysis and map the modules identically with the red button. You can use this freely available ROM to reproduce this: https://itch.io/jam/gbajam21/rate/1120303
2. Once everything is setup, go to the objects window and click play
3. On mgba, click “Break” on the GDB server window. This will send a stop reply pack so GDB can stop.
4. Repeat steps 2-3 until an error pops up. This is inconsistent: you MAY see the error, but it’s not guaranteed (see notes at the bottom as to why I think this is happening).

Expected behavior To not see the error. It happens often enough to be distracting. If I need to disassemble manually, I can do it so it’s not even necessary for the disassemble to work first try, but it would be a bonus.

Screenshots This is how my Ghidra looked right as I got the error (after I pressed ok)

Environment (please complete the following information):

• OS: Arch Linux kernel 5.16.15-arch1-1
• Java Version: openjdk 11.0.15 2022-04-19
• Ghidra Version: 10.1.1
• Ghidra Origin: official ghidra-sre.org distro

Additional context This is my personal speculation here, but the GameBoy Advance is a little unconventional target because although its CPU is an armv4t, it is mostly used in thumb mode and only sometimes in ARM mode. What seems to happen is it seems Ghidra guesses the mode it’s in wrong so it tries to disassemble, but fails. This could explain the inconsistency of the issue (you may need to land in code with a specific thumbness or specific layout).

This is the full error message text:

java.lang.NullPointerException
	at ghidra.trace.database.context.DBTraceRegisterContextSpace.setValue(DBTraceRegisterContextSpace.java:269)
	at ghidra.trace.database.listing.DBTraceInstructionsView.doSetContexts(DBTraceInstructionsView.java:175)
	at ghidra.trace.database.listing.DBTraceInstructionsView.doCreate(DBTraceInstructionsView.java:214)
	at ghidra.trace.database.listing.DBTraceInstructionsView$InstructionBlockAdder.doCreateInstruction(DBTraceInstructionsView.java:73)
	at ghidra.trace.database.listing.DBTraceInstructionsView$InstructionBlockAdder.doAddInstructions(DBTraceInstructionsView.java:146)
	at ghidra.trace.database.listing.DBTraceInstructionsView.addInstructionSet(DBTraceInstructionsView.java:387)
	at ghidra.trace.database.listing.DBTraceInstructionsMemoryView.addInstructionSet(DBTraceInstructionsMemoryView.java:78)
	at ghidra.trace.database.program.AbstractDBTraceProgramViewListing.addInstructions(AbstractDBTraceProgramViewListing.java:739)
	at ghidra.program.disassemble.Disassembler.disassemble(Disassembler.java:625)
	at ghidra.program.disassemble.Disassembler.disassemble(Disassembler.java:489)
	at ghidra.app.cmd.disassemble.DisassembleCommand.doDisassemblySeeds(DisassembleCommand.java:327)
	at ghidra.app.cmd.disassemble.DisassembleCommand.doDisassembly(DisassembleCommand.java:309)
	at ghidra.app.cmd.disassemble.DisassembleCommand.applyTo(DisassembleCommand.java:155)
	at ghidra.app.plugin.core.debug.workflow.DisassembleAtPcDebuggerBot$ForDisassemblyTraceListener$1.applyTo(DisassembleAtPcDebuggerBot.java:306)
	at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:102)
	at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:319)
	at java.base/java.lang.Thread.run(Thread.java:829)

---------------------------------------------------
Build Date: 2021-Dec-21 1319 EST
Ghidra Version: 10.1.1
Java Home: /usr/lib/jvm/java-11-openjdk
JVM Version: Oracle Corporation 11.0.15
OS: Linux 5.16.15-arch1-1 amd64
Workstation: aldelaro5-PC.localdomain

[d-millar]

cool - thanks. have everything I need now except Ghidra, which I’m having trouble building (LOL)

[aldelaro5]

Ok I just upgraded and restested both versions and yeah, it appears it’s fixed as of 10.1.2 so I will be closing this.