Debugger stepping issues on Linux

[rcstuber]

TLDR; Stepping through code and editing breakpoints is potentially broken on Linux (must be verified)

There are a two potential issues with the single-step mechanism on Linux:

1) When a temporary breakpoint is set to stop at the next line of code (stepping), the breakpoint is deleted right after being hit. This causes the nextStep variable to be reset to -1. Thus when running subsequent resume()and wait() calls the CPU (eflags register) will still be in single-step mode and will not be able to recover from that.

2) When removing a breakpoint which we are currently stopped on, the nextStep variable is also reset to -1, also leaving the execution in single-step mode and preventing continuation.

Requirements: The implementation must both support single-step after a persistent breakpoints to restore the BP upon stepping over it AND single-step without side-effects in order to support stepping into functions instruction by instruction.

Solution: 1 . The Linux API should return a proper SingleStep exception code, instead of a generic Breakpointcode.

2. When removing a breakpoint the thread is currently stopped on, the single-step (eflags) must be explicitly reset. The native Windows API apparently exits single-step mode automatically when resuming execution.

Note For Linux this was not tested hands-on by me (currently no Linux on my system), but the issues were detected while implementing the Mac Debugger API, which behaved identical. Someone please verify this behavior on an actual system.

I can commit fixes for Linux together with the upcoming Mac implementation, since they are sort of needed for both.

Cheers

[kLabz]

I can confirm something is indeed wrong on linux, debugger crashes when trying to catch uncaught "null accesss" exception. Not sure what I can do to help with this.

[ncannasse]

Please provide a PR with OSX fixes that should also apply to Linux ;)

[rcstuber]

Issue might be related: https://github.com/vshaxe/hashlink-debugger/issues/56

Will look into it asap I find some space on my hard drive to install Linux

[Babouchot]

Hey :wave:
I noticed there are still some issues preventing the use of the vscode debugger on linux (the CLI seems to work fine). I found out that, in the end, @rcstuber incorporated mac support into the main tree with this commit : 35b7d34a56c6be5915c41ff1dab6667cc2651dda but from what I see it does not impact the linux implementation. I tried replacing the Breakpoint code with SingleStep as you suggested in the wait function but it did not work out, I guess I'm missing something here :thinking: And since the macOS implementation seems to have been added in external symbols, I can't really use it as a reference. Do you have any hints so that I could help further ?

[rcstuber]

Hi there!

So shame on me, as I never delivered on the promise to provide Linux fixes with the Mac implementation. I think there are two remaining problems:

1) Linux wait function must return SingleStep (=2) code when hitting a single step break 2) The waitpid function should be non-infinitely-blocking, since that will cause issues when non breakpoint was set on debugger launch, as the first wait will wait indefinitely

The solution mentioned in my original post under point 2 should have been fixed with the Mac commit.

So how to proceed:

1) https://github.com/HaxeFoundation/hashlink/blob/bea1af67d7cb1404b6623c276715160f83d00fa3/src/std/debug.c#L247

Here it should also check if it is a permanent (i.e. user set) breakpoint or a single step BP and return status code 2 in the latter case, instead of 4

2)

https://github.com/HaxeFoundation/hashlink/blob/bea1af67d7cb1404b6623c276715160f83d00fa3/src/std/debug.c#L235

The waitpid is waiting indefinitely. There is a non-blocking waitpid flag, but it will essentially cause a crazy loop, so what I did with the Mac implemention (although it doesn't use waitpid) is to have a timeout and use a semaphore to pause/resume the thread, see: https://github.com/HaxeFoundation/hashlink/blob/bea1af67d7cb1404b6623c276715160f83d00fa3/include/mdbg/mdbg.c#L820

That's what I can remember so far. And these changes need to go both in the debug.c and in the VSCode implementation.

Wrote this from my phone, so excuse the messy steno. I can give you more details once back at my laptop on monday.

Cheers & have a good weekend!

[Babouchot]

Thanks for the insights ! And sorry, I didn't mean to shame you at all ! :cold_sweat: I'll try to look into that if I find the time but if someone with more experience of the codebase wants to do it, please go, I'm just getting on board of the Haxe train :slightly_smiling_face:

[haddock7]

I left recently a comment on the main Haxe forum about this issue. So I can confirm that the bug is still here on Linux with the latest release of the debugger in VSCode.

Here is what I wrote:

In Visual Studio Code, when I add a breakpoint and run a hashlink application, the execution stops correctly at that breakpoint > but further step into doesn’t work (actually I have to step into many times to enter a function). Also a step over is very unreliable, and a continue command blocks the execution, I have to kill the application.

I have tested on a fresh basic project, it behaves the same. However, on Windows, it works properly.

I’m using the latest versions of tools/libraries:

Ubuntu 20.04 Visual Studio Code 1.49.2 haxe 4.1.4 hashlink 1.11.0 compiled from source code Latest versions of VS Code extensions.

On Windows, except the OS, all is the same version.

[ghost]

I have several problems using the debugger on Linux with VsCodium. On Windows the debugger works fine while on Linux it steps (the step button must be pressed twice) but when debugging is resumed the application crashes: the command line debugger instead works fine on Linux so I suspect it's a problem with some linux specific thing that the extension does.

Has anyone had any luck in successfully debugging the extension? No good luck so far from my side sadly :disappointed:

[yuxiaomao]

I cannot reproduce step/breakpoint error now, so I'll considered that they are fixed. For waitpid I have a hack for 1.4.9 https://github.com/vshaxe/hashlink-debugger/commit/6e7d3794c94704d71314a19457628dedb77f1eee , let's see if it can allow me to avoid implementing semaphore