vshaxe
Debugger not functioning on Linux in VSCode
Symptoms:
With
{
"name": "HashLink",
"request": "launch",
"type": "hl",
"cwd": "${workspaceFolder}",
"internalConsoleOptions":"openOnSessionStart",
"preLaunchTask": "${defaultBuildTask}"
}
App compiles, opens and runs, and debug controls (with pause, step, rebuild, stop) appear.
However:
- No trace output or error information goes to the debug panel
- Upon closing the app, all output appears in the debug panel at once
- Breakpoints trigger the debugger, but clicking 'continue' crashes VSCode and leaves a zombie
adapter.jsprocess which consumes a lot of CPU - The 'pause' button is not functional
- The 'restart' button recompiles but does not launch
- The 'stop' button closes the debugger without closing the program
- Closing the program does correctly close the debugger as well, though
With a running hl --debug 6112 out/hl/main.hl in the VSCode terminal and
{
"name": "HashLink (attach)",
"request": "attach",
"port": 6112,
"type": "hl",
"cwd": "${workspaceFolder}",
}
The error Failed to initialize debugger appears, with options to dismiss the error or open launch.json.
Perhaps interestingly, with hl --debug 6112 --debug-wait out/hl/main.hl, the app appears at the same time as the Failed to initialize debugger message, as if the debugger it had been waiting for had attached, but of course the debugger does not open.
Software Versions:
- VSCode:
1.78.0(Also replicated with prior version1.77._) - HashLink Debugger:
1.3.4(Similar issues when built from latest git * source) - Haxe:
4.3.1 - HashLink:
1.13.0 - Heaps:
Git latest - Linux flavor:
Ubuntu (Mint)
Notes:
- With the above configs/project, the debugger works as expected on Windows 11
- There is at least one other person with a similar issue and no resolution in the thread
- There is also this relatively recent comment on an older Linux issue which mentions the 'crash on step' behavior as well
- When using the extension built from git latest source, symptoms are similar except the app itself also fails to launch using the first of the two configs
- When triggering a breakpoint with the first method, everything seems to be working as intended for that moment; variables appear in inspector and show on hover
I would be very obliged if there are any hints at how to solve this or where best to begin investigating.
Addendum: I have just reproduced the exact same behavior on Arch (Manjaro).
Out of curiosity, what's the value of your /proc/sys/kernel/yama/ptrace_scope ?
Out of curiosity, what's the value of your
/proc/sys/kernel/yama/ptrace_scope?
Hello,
cat /proc/sys/kernel/yama/ptrace_scope
Gives
1
Set it to 0. That would at least resolve the issue with attaching to a running process, and maybe some you have in launch mode.
(https://www.kernel.org/doc/Documentation/security/Yama.txt. Btw, you can make it permanent by editing /etc/sysctl.d/10-ptrace.conf)
Set it to
0. That would at least resolve the issue with attaching to a running process, and maybe some you have in launch mode. (https://www.kernel.org/doc/Documentation/security/Yama.txt. Btw, you can make it permanent by editing/etc/sysctl.d/10-ptrace.conf)
That does seem to at least let debug information from the debugger reach the VS Code console, and I no longer seem to be getting zombie processes.
As with before, I can only trap the first breakpoint. Resuming now throws the trace:
***** ERRROR ***** Could not resume 261110
Called from .new haxe_ValueException (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/adapter.js line 3554 column 3)
Called from haxe_Exception.thrown (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/adapter.js line 3180 column 12)
Called from hld_Debugger.resume (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/adapter.js line 7590 column 25)
Called from hld_Debugger.wait (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/adapter.js line 6849 column 10)
Called from hld_Debugger.run (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/adapter.js line 6649 column 15)
Called from module at /home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/adapter.js:1257:33
Called from HLAdapter.safe (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/adapter.js line 1217 column 11)
Called from HLAdapter.continueRequest (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/adapter.js line 1256 column 8)
Called from HLAdapter.dispatchRequest (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/node_modules/vscode-debugadapter/lib/debugSession.js line 405 column 22)
Called from HLAdapter.handleMessage (/home/user/.vscode/extensions/haxefoundation.haxe-hl-1.4.4/node_modules/vscode-debugadapter/lib/protocol.js line 61 column 18)
The call to hld_Debugger.resume seems to end up into https://github.com/vshaxe/hashlink-debugger/blob/master/hldebug-wrapper/src/debug.c#L295. Yet another failing call to ptrace.
If you try and attach a "standard" native debugger to the hashlink process, such as gdb. Can you break into the code (ctrl+C) resume (cont), etc ?
The call to
hld_Debugger.resumeseems to end up into https://github.com/vshaxe/hashlink-debugger/blob/master/hldebug-wrapper/src/debug.c#L295. Yet another failing call toptrace. If you try and attach a "standard" native debugger to the hashlink process, such as gdb. Can you break into the code (ctrl+C) resume (cont), etc ?
Yes, with ptrace_scope set to 0, I can attach gdb to a running HL process, set breakpoints, continue from them, etc. It seems to work normally.
All listed point fixed in the version 1.4.9, with a message about ptrace_scope. Tested on my Ubuntu 22 VM with VSCode and a game project. There is a hack however https://github.com/vshaxe/hashlink-debugger/commit/6e7d3794c94704d71314a19457628dedb77f1eee (but without it the code would be more complexe - semaphore and thread - that I didn't managed to get it works yet), so please tell me if the "display hl output in nearly realtime" is broken on your system, and provide details about your system's configuration.
@yuxiaomao
Thank you for your work on this!
I confirm that breakpoints (including set at runtime), resuming, inspecting variables, capturing 'trace' output in the debug panel, and using the 'stop' button on the vscode debug control panel all now work on the systems outlined in the original issue report using Hashlink git latest and Hashlink debugger v1.4.9 from the plugin marketplace.
The 'pause' button on the control panel seems to not have any effect, though I cannot actually remember if this worked on Windows either.
@kaug-whis Glad to know that my fix works (mostly) for you! "Pause" works on Windows 11 and on Ubuntu 22 for me.
It's a little bit strange because setting breakpoints on runtime will actually pause and resume hl on this version.
I would like know your OS, if you reproduce with a simple project (e.g. sleep inside a loop) and if you have more information when activate "verbose" mode in hashlink-debugger extension settings ("hldebug.verbose" : true) - normally it have "pause request" then "stopped on tid".
@yuxiaomao
I'm testing on Linux Mint 21.3 Virginia (upstream is Ubuntu 22.04), in this case, with ptrace 0.
With a minimum project (just while(true) Sys.sleep(0.1);) the behavior is the same.
In verbose, the output is:
0> src/HLAdapter.hx:66: Initialize
0> src/HLAdapter.hx:87: Launch
0> src/HLAdapter.hx:247: Start process hl [--debug-wait,--debug,6112,out/hl/test.hl] pid=18656
0> src/HLAdapter.hx:298: Load module out/hl/test.hl
0.3> src/HLAdapter.hx:301: Connecting to 127.0.0.1:6112
0.4> src/HLAdapter.hx:407: Skip thread 18656
0.4> src/HLAdapter.hx:330: Connected
0.6> src/HLAdapter.hx:336: Init done
29.2> src/HLAdapter.hx:876: Disconnect request
29.7> src/HLAdapter.hx:278: Exit code null
29.7> src/HLAdapter.hx:1070: Dispose
After 'init done', I pressed 'pause' multiple times but got no output.
In fact, I could also reproduce it on Ubuntu22 when I do not have a initial breakpoint. Fixed in https://github.com/vshaxe/hashlink-debugger/commit/b3837f422405371f57d3749215507687b45fc809 Will be released in the next version, probably this week.