Describe the bug
When using the Pcode Emulator specifically, inst_next2 occasionally evaluates to inst_next rather than being computed correctly. The logic that causes this is in SleighParserContext.getN2addr(), where failure of the call to computeNext2Address() causes a fallback to inst_next.

This seems like an inappropriate behavior, as I can't think of any case where a user would want this to happen silently rather than displaying an error message of some kind. Depending on what inst_next2 is used for in the sleigh spec, this could cause the emulated code to behave differently than expected. On top of this, the pcode that's actually displayed to the user in the Listing view is calculated with a different codepath that doesn't have this issue, adding to the confusion.

While this issue could in theory happen any time an instruction is disassembled, it happens more often in the emulator because the backing SleighParserContext.memBuffer is set to the current PseudoInstruction by DefaultPcodeThread.getContextAfterCommits(). PseudoInstruction contains a limited number of cache bytes, the size of which is calculated in PseudoInstruction.getByteCacheSize(). The cache size usually ends up being the length of the instruction plus 3, which is usually not enough to parse the next two instructions needed to calculate inst_next2. This is in contrast to the normal disassembly path that uses SleighLanguage.parse(), which passes a MemBuffer instance that is able to fall back to the entire program's memory.

To Reproduce
I attached a simple processor module and test program. Running the first instruction in the emulator should illustrate the issue.

Screenshots

Attachments
inst_next2_repro.zip

inst_next2_repro_gzf.zip

Environment (please complete the following information):

• OS: Ubuntu 22.04
• Java Version: Adoptium 21.0.8
• Ghidra Version: 11.4.2
• Ghidra Origin: Official GitHub distro