Advanced Error Handler and Debugger

I stumbled across a bug that makes the error message quite difficult to read in very specific circumstances:

 

Pacguy, wow, that's some amazing find. It's actually the first time since the release (that I'm aware of, at least) someone managed to effectively crash the crash handler~

Comments in your video are mostly correct. This is indeed error handler trying to decode corrupted label name, which causes it to hang. All symbol data is encoded and compressed to save space and due to the nature of my compression, the decompressor is really sensitive to random/incorrect data. However, I have all sorts of safe checks to avoid feeding it with wrong entries (v1 also implemented a rough counter just to avoid endless loops during decompression, but I had to drop it in v2 because I was out of space and registers). But there are intentionally added edge cases of course, to make finding symbols smarter of course.

* * *

Please try the hotfix of the error handler blob (from the attached archive), to see if it fixes this issue.
If it does, congratulations, you've discovered quite a rare edge case!
In fact, nearly impossible set of circumstances had to be met: 1) trying to resolve label (symbol) for a very specific offset in a specific 64-kb section past the ROM area, 2) so an incorrect block in the symbols data was loaded, 3) which had to be corrupted in a specific way to be able to point to a specific random data, 4) which had to have a certain sequence of bytes to manage to put symbol decoder in an endless loop. Just wow, you should've been really unlucky to pull that off.

I believe it's your case, seeing the offset of exception is 872000D4, which error handler decodes to 2000D4, because M68K on MD has 24-bit address bus and upper 8 bits of address do not matter. Offset 2000D4 is just slightly after 2 MB of ROM space. In case your ROM is 2 MB, the offset points just slightly after the last block of your ROM. This triggers an edge case to help resolve offsets that may refer to the last label in the ROM.

Say, you have the following at the end of your ROM:

Code:

block 1F, full offset: $1FFFFF: EndOfROM:
block 1F, full offset: $1FFFFF:   dc.b   'This is the end of my ROM'
block 20, full offset: $200018:   dc.b   '(c) 2018, me'
block 20, full offset: $200024:   dc.b   0

The "EndOfROM" is the last label ConvSym will record, but there's some data past it that we can point to.
Being smart, error handler will decode offset $200018 into EndOfROM+$19 ($1FFFFF+$19 = $200018).

This is actually a tricky edge case. There are technically no labels declared in block 20 (offsets $20xxxx), it's non-existent.
Normally, the error handler could've stopped and return '<undefined>' for this offset. But if it detects the offset to be located after the last defined block, it'll try to resolve it with the last label of the last block. There was a small oversight/bug in this logic, that is hopefully gone with the hotfix.

Please let me know if it works. If it does, I'll update Error handler with this fix.

 

The hotfix actually seems to have no effect at all! The behavior still occurs, exactly as it did before. I'm happy to supply more info if necessary.

 

Now this gets even more interesting. I was quite sure it was an oversight for the edge case I described.

Yes, more details would be nice. I'd like to see what really causes this crash to occur. If you can, please PM me your ROM and your .LST-file that is used to generate symbols data, that's all I need to to debug the issue.

 

As it turns out, the issue was a user error type situation. Although I didn't notice it, the rom actually exceeded 4mb after the symbol data was appended, so the error handler ended up interpreting whatever was past the 4mb range as symbol data, since the data was truncated.