Debugger crash in V1.8.4, V1.8.5 and V1.8.6 on Linux - V1.8.2 works - Example code inside.

[Jasmin68k]

Hi!

I tried out this tool today for the first time on a box running Debian Sid and noticed that it's quite easy to crash the debugger on my system for the versions given in the title (V1.8.2 works).

See below for the simplest example code I could come up with to reproduce the issue. The code crashes on the second movem like this:

V1.8.4: FS-UAE just hangs and in VSCode one is left in the debug console with no further info, the debug console still accepts commands. V1.8.5: Exception has occured: 11 Exception: 0x00fc090e: cmpi.l #$fc08e6, $2(a7) -> This address is the location of the crash in V1.8.6 V1.8.6: Exception has occured: 2 Interrupt: 0x00fc08e6: ori.w #$2000, sr

I also noticed that LD_LIBRARY_PATH seems not to be used, since I had to install libsdl2-ttf-2.0-0 to get the bundled fs-uae to run from VSCode (otherwise "[EMU] No suitable emulator binary" error). Maybe this is related to the issue.

Example code:

movem.l     d0-a6,-(sp)
movem.l     (sp)+,d0-a6
clr         d0
rts

Running with "noDebug": true FS-UAE runs normally.

I hope you can reproduce the issue on your end and find the cause.

[prb28]

@grahambates can you look at this please ?

[prb28]

I managed to debug on ubuntu 22.04 even if I had the same issue. Please try:

• chmod u+x /home/user/.vscode/extensions/prb28.amiga-assembly-1.8.7/dist/bin/fs-uae/fs-uae-linux_x64
• Modify your ~/.bashrc export LD_LIBRARY_PATH=/home/user/.vscode/extensions/prb28.amiga-assembly-1.8.7/dist/bin/fs-uae
• uncheck the "All Exceptions" in the breakpoints view
• Start debuging with fs-uae I'll try with a debian 12 vm when it will be ready.

[grahambates]

Regarding executable flag, uae-dap tries to fix this and chmod the binary before executing it. Obviously it's not working in this case. Perhaps it doesn't have permission to do so in Linux. I'll look into this.

[prb28]

The workaround is efficient on debian 12 too.

[djyt]

@prb28 I can confirm from a quick test that unchecking "All Exceptions" has fixed the issue and I can debug. Awesome.

[Jasmin68k]

@prb28

I tested this again using V1.8.7 pre-release version.

The chmod was not necessary, +x was already set.

I then tested with the LD_LIBRARY_PATH set as well as without it and with libsdl2-ttf-2.0-0 installed instead (in order to not get the "[EMU] No suitable emulator binary" error).

I also tested with and without "All exceptions" set.

In all cases what happens is the following:

The debugger stops on the second instruction movem.l (sp)+,d0-a6, even if there's no breakpoint set, but it doesn't crash as before or land at some other unrelated instruction as originally. So continuing will either finish or stop at the next actually set breakpoint, debugging seems to work except for that stop at the second instruction.

If I comment out movem.l (sp)+,d0-a6, it stops at clr d0, so again, it's the second instruction.

A breakpoint at the first instruction is ignored, it still stops at the second instruction.

A breakpoint at the second instruction, doesn't change anything.

Only with "All execeptions" set it now crashes after the code finishes at: 0x00fc08e6: ori.w #$2000, sr, where it crashed before as described in the original post.

So disregarding the unprompted stop at the second instruction and a breakpoint not working at the first instruction, with "All exceptions" unset, debugging seems to work.

[prb28]

@Jasmin68k In the default launch configuration the "stopOnEntry": true, option is set. This makes the program stop at the second instruction. There is no way to stop it at the first instruction. If you set this option to false, it will continue until your first breakpoint.

[Jasmin68k]

@prb28 Ok, great, thanks, missed that.