llvm / llvm/llvm-project

lldb-dap crash on windows when python script formatter are used

Open
#177,373 1 comment 0 reactions 0 assignees View on GitHub
crash lldb-dap platform:windows
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

I am running lldb-dap in vscode and getting crashes when using python scripts to format variables.

I have made a minimal repro here: [lldb-dap_crash.zip](https://github.com/user-attachments/files/24797448/lldb-dap_crash.zip). The archive contains a script that run lldb-dap a perform two commands that get it to crash:
- initialize lldb
- launch the executable with a init commands arg.

Note that commenting out line 161 in repro.ps1 (sending the init command) stop lldb.dap from crashing.

The script produce a crashdump but I don't have any of the symbols available to decode the stacktrace.

The logs from lldb-dap are:
>1769093070.899796247 (stdio) --> {"command":"initialize","arguments":{"columnsStartAt1":true,"linesStartAt1":true,"clientID":"vscode","adapterID":"lldb-dap","pathFormat":"path"},"type":"request","seq":1}
>1769093070.916259527 (stdio) <-- {"body":{"$__lldb_version":"lldb version 21.1.8","completionTriggerCharacters":["."," ","\t"],"exceptionBreakpointFilters":[{"description":"C++ Catch","filter":"cpp_catch","label":"C++ Catch","supportsCondition":true},{"description":"C++ Throw","filter":"cpp_throw","label":"C++ Throw","supportsCondition":true},{"description":"Objective-C Catch","filter":"objc_catch","label":"Objective-C Catch","supportsCondition":true},{"description":"Objective-C Throw","filter":"objc_throw","label":"Objective-C Throw","supportsCondition":true}],"supportTerminateDebuggee":true,"supportsBreakpointLocationsRequest":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsDisassembleRequest":true,"supportsEvaluateForHovers":true,"supportsExceptionFilterOptions":true,"supportsExceptionInfoRequest":true,"supportsFunctionBreakpoints":true,"supportsHitConditionalBreakpoints":true,"supportsInstructionBreakpoints":true,"supportsLogPoints":true,"supportsModulesRequest":true,"supportsReadMemoryRequest":true,"supportsSetVariable":true,"supportsSteppingGranularity":true,"supportsValueFormattingOptions":true,"supportsWriteMemoryRequest":true},"command":"initialize","request_seq":1,"seq":0,"success":true,"type":"response"}
>1769093070.957221508 (stdio) --> {"command":"launch","arguments":{"initCommands":["command script import script.py"],"program":"D:/git/A/out/build/navigation-vdb-ClangCL-x64-debug-lldb/Public/Demo/Demos/Demos.exe"},"type":"request","seq":2}

And then it just crash without outputting any errors

Note that running lldb directly work:
> PS D:\WORK_DIR\lldb-dap_crash> lldb notepad.exe
>(lldb) target create "notepad.exe"
>Current executable set to 'C:\WINDOWS\SYSTEM32\notepad.exe' (x86_64).
>(lldb) command script import script.py
>hello world

I am on Windows 11 with LLVM installed with the windows installer from https://github.com/llvm/llvm-project/releases/tag/llvmorg-21.1.8

lldb-dap version:
>PS D:\WORK_DIR\lldb-dap_crash> lldb-dap.exe --version
>lldb-dap: LLVM (http://llvm.org/):
> LLVM version 21.1.8
> Optimized build.
>liblldb: lldb version 21.1.8

Python version (that the only version I have installed)
> PS D:\WORK_DIR\lldb-dap_crash> python --version
> Python 3.10.11
>PS D:\WORK_DIR\lldb-dap_crash> py -0
> -V:3.10 * Python 3.10 (64-bit)

Contributor guide

Open the contributing guide

Research direction

Start by running the attached lldb-dap_crash.zip repro, especially repro.ps1 and its line 161 init command, using the reported Windows and Python versions. Compare the DAP initialize and launch sequence with the direct lldb command-script import; done means lldb-dap no longer crashes when initCommands imports the Python formatter script.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, vscode
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.