Advanced Error Handler and Debugger

Discussion in 'Utilities' started by vladikcomper, Apr 5, 2016.

  1. Pacca

    Pacca Level 1 inflatable otter thing Member

    Joined:
    Jul 5, 2014
    Messages:
    1,128
    Location:
    The Moon (again)
    I stumbled across a bug that makes the error message quite difficult to read in very specific circumstances:
     
    Natsumi likes this.
  2. vladikcomper

    vladikcomper Well-Known Member Member

    Joined:
    Dec 2, 2009
    Messages:
    382
    Location:
    Russia
    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.
     

    Attached Files:

    Natsumi likes this.
  3. Pacca

    Pacca Level 1 inflatable otter thing Member

    Joined:
    Jul 5, 2014
    Messages:
    1,128
    Location:
    The Moon (again)
    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.
     
  4. vladikcomper

    vladikcomper Well-Known Member Member

    Joined:
    Dec 2, 2009
    Messages:
    382
    Location:
    Russia
    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.
     
  5. Pacca

    Pacca Level 1 inflatable otter thing Member

    Joined:
    Jul 5, 2014
    Messages:
    1,128
    Location:
    The Moon (again)
    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.
     
    vladikcomper likes this.
  6. Clownacy

    Clownacy Grumpy Staff

    Joined:
    Aug 15, 2014
    Messages:
    861
    I've never used this before, but it looks like there are a few problems with the installation guide, at least for Sonic 2.

    The first problem is that ConvSym is only ran if AS didn't print any warnings. It's an edgecase, but I ran into the problem after deliberately inserting a 'move.w (1).w,d0' into my ROM to trigger the debugger.

    The second problem is that, after ConvSym is ran, the ROM's header isn't amended to account for the new ROM size, causing emulators with an auto-checksum-fix to break the checksum check.

    Both of these problems can be fixed by just editing build.bat:

    First, undo the installation guide's edit by changing this:
    Code:
    IF EXIST s2built.bin (
       convsym s2.lst s2built.bin -input as_lst -a
       exit /b
    )
    ...back to this:
    Code:
    IF EXIST s2built.bin exit /b
    Then insert a new call to ConvSym at the proper place by inserting this:
    Code:
    IF EXIST s2built.bin convsym s2.lst s2built.bin -input as_lst -a
    ...before this:
    Code:
    IF EXIST s2built.bin "win32/fixheader" s2built.bin
     
    FireRat and Pacca like this.