Issue with Debugging After Upgrading to CodeLLDB 1.11.2 and greater

[kiv07]

Hi CodeLLDB Team,

I am facing an issue after upgrading from CodeLLDB 1.11.1 to 1.11.2 (or the latest version).

Previously, our image debugging worked fine using the “custom” attribute. However, since the “custom” attribute has been deprecated in CodeLLDB 1.11.2, I modified my launch.json to use "request": "launch" along with "targetCreateCommands" and "processCreateCommands" as suggested.

The problem I am facing with the new configuration is that after the debuggee process is created, I need to manually press the pause button in the VSCode debug toolbar to start further debugging. By default, the debug toolbar should show as paused because execution stopped at breakpoint.

Could you please help provide guidance on how to resolve this issue and explain why it might be related to the configuration using "request": "launch" along with "targetCreateCommands" and "processCreateCommands"?

Thank you.

[vadimcn]

Are you launching or attaching? Can you share your specific launch configuration?

[kiv07]

Hi CodeLLDB Team,

I am really sorry for the delayed response. I was checking on the latest version of codelldb to see if the issue resolves itself.
I am using the "attach" request. On codelldb1.11.4 also we have same pause issue.

I tried reproducing the issue with simple c code on latest codelldb 1.11.4.

First ,I start the GDB server with executable a.exe using command
"gdbserver localhost:2000 a.exe"

Which starts the execution of program a.exe on the target machine opens a connection on port 2000 and waits for the debugger to connect.

Connecting to program a.exe using below configuration from VSCode (using same configurations for codelldb 1.11.3 and greater):
{
"version": "0.2.0",
"configurations": [
{
"type": "lldb",
"request": "launch",
"name": "Debug",
"cwd": "${workspaceFolder}",
"breakpointMode": "file",
"stopOnEntry": true,
"targetCreateCommands": [
"script os.chdir("scripts")",
"command script import lldb_temp.py",
"target create c:/Test_code/code/a.exe",
],
"processCreateCommands": [
// "gdb-rem 2000",
"custom_attach", //Not working
]
}
]
}

cutom_attach in processCreateCommands is lldb custom command which was created to handle "gdb-rem 2000" command from script (as shown in scripts/attach.py file).

So when I run "Debug" configuration from VScode, the expectation is to see the the debug process halted and allow us for further debug.
but with latest codelldbs, we need to manually pause from Vscode debug toolbar to make sure the process has halted/stopped.

### Note: The pause issue does not occur if I put the "gdb-rem 2000" command directly in launch.json and comment out the custom_attach command as shown below.
{
"version": "0.2.0",
"configurations": [
{
"type": "lldb",
"request": "launch",
"name": "Debug",
"cwd": "${workspaceFolder}",
"breakpointMode": "file",
"stopOnEntry": true,
"targetCreateCommands": [
"script os.chdir("scripts")",
"command script import lldb_temp.py",
"target create c:/Test_code/code/a.exe",
],
"processCreateCommands": [
"gdb-rem 2000", //Working.
// "custom_attach",
]
}
]
}

I am attaching
code.zip
the zipped workspace where I reproduced the issue. The scripts folder contains Python files that handle creating custom LLDB command and a function to perform the gdb-rem connection.

Please help with inputs on why the issue could be occurring when using scripts but not directly from launch.json.
will be looking forward for your guidance.

Thank you.

[kiv07]

Hi CodeLLDB Team,

Could you please help with this? Why is a manual pause required when we include a custom LLDB command in launch.json, but this issue does not occur when we include the LLDB command directly in launch.json?

Your input on this issue would be really helpful, as we are performing image debugging in a similar way.
please help on this.

[vadimcn]

Why is a manual pause required when we include a custom LLDB command in launch.json, but this issue does not occur when we include the LLDB command directly in launch.json?

Determining whether the debuggee is running or stopped after a custom launch command sequence is kinda flaky, so it's possible that the debug UI is not reflecting the actual state of the debuggee. What you are observing is probably due to a small timing variation between the two methods.
Sorry, I don't have a solution at this time. Maybe try using lldb-server rather than gdbserver, if possible - I've noticed that lldb often works better with its own debug server.

[kiv07]

Sure. I can give it a try using lldb-server for debugging a simple program.
However, for image debug we cannot use lldb-server as we are using OpenOCD debugger, which starts gdbserver to connect to the target.

I can definitely try it for a simple program just to check if gdbserver causing any issues.

[kiv07]

I was checking lldb verbose logs for the working and non-working cases.
I found a debug event log in the working case, which is missing in the non working case.
[DEBUG codelldb::debug_session] Debug event: 0000021760AAFB20 Event: broadcaster = 0000021760A925F8 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0000021760A925D0 (pid = 23584), state = stopped}

Diff snippet is below.

Attaching log files for reference
custom_lldb_cmd_logs.txt - non working case log file
lldb_cmd_logs.txt - working case log file.

Could this debug log make sense regarding the pause issue?
Is this a kind of signal sent from CodeLLDB to VSCode indicating that the process has been stopped?

Can you please help check the logs to see if they provide any clues about the pause issue?

Thank you.

[vadimcn]

That's a notification from the LLDB engine, which is relayed to VSCode. As you can see, sometimes it goes missing. So far, I was unable to figure out how to receive it reliably.

[kiv07]

Hi,

I tried using lldb-server, but it did not help. I'm still encountering the same issue. A manual pause is required when using custom LLDB commands in launch.json

It's unusual that this issue is occurring with the latest codelldb versions, where the "custom" launch configuration has been deprecated and started using "request": "launch" along with "targetCreateCommands" and "processCreateCommands".

We did not experience any such pause issues until codelldb 1.11.1, when we were using "request": "custom" along with "initCommands" and "targetCreateCommands".

[kiv07]

Just to make sure I'm doing it correctly, sharing lldb-server command and launch.json configuration.

Starting lldb-server on executable :
lldb-server gdbserver localhost:2000 a.exe

launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "lldb",
"request": "launch",
"name": "Debug",
"cwd": "${workspaceFolder}",
"breakpointMode": "file",
"stopOnEntry": true,
"targetCreateCommands": [
"script os.chdir("scripts")",
"command script import lldb_temp.py",
"target create c:/Test_code/code/a.exe",
],
"processCreateCommands": [
"gdb-remote localhost:2000",
// "custom_attach", -> custom lldb command which executes "gdb-remote localhost:2000"
]
}
]
}

please correct, if i did something wrong.

[kiv07]

Hi Vadimcn,

The changes in launch.rs and sbprocess.rs highlighted in the screenshots seem to be address the pause issue in the latest codelldb 1.11.4.
Attaching archive files for your reference.
launch.zip
sbprocess.zip

I have also tested in on my setup.
Could you please review the code changes to see if they are acceptable?
will be looking for you further guidance.

[vadimcn]

Not so simple, unfortunately: during a launch, the process may transiently be in a "stopped" state due to some internal LLDB behavior. In these cases, this change causes the client to wrongly believe that the debuggee is in a stopped state, when it really isn't.

I'd recommend trying the "attach" request type instead, as it handles this a bit differently. gdb-remote is an alias for process connect..., so "attach" is semantically closer to what's actually happening.

[kiv07]

I'd recommend trying the "attach" request type instead, as it handles this a bit differently. gdb-remote is an alias for process connect..., so "attach" is semantically closer to what's actually happening.

Using the "attach" request is not helping; the program continues executing when we connect to the gdbserver using gdb-remote localhost:2000.
This behavior is not what we expect during image debugging. If the target is halted or stopped at a breakpoint, it should remain in a stopped state when we connect, allowing us to continue debugging from that point.

"Is there a CodeLLDB configuration that stops execution after hitting a breakpoint or shows the process as paused in the UI when using the 'attach' request?"

[vadimcn]

Try "postRunCommands": ["process interrupt"]

[kiv07]

Try "postRunCommands": ["process interrupt"]

I tried using the postRunCommands configuration with attach to prevent the program from continuing execution, which helped show the process as halted or stopped in the UI

But I am facing an issue when I try to continue, the process stops due to a SIGINT exception.
So, we can't use the attach request for image debugging.

Note: With the "request: launch", things are working fine except for the manual pause.
Could you please suggest if this can be handled somehow based on the code changes that are working for us?

[vadimcn]

Try v1.11.5, I think it should be better now.

[kiv07]

Try v1.11.5, I think it should be better now.

Sure. will check on this.

[kiv07]

I need some understanding of the 'attach' request in the context of codelldb. As we are doing remote debugging, does the attach request just attach to a process without changing the process state?
We are considering which option is more suitable for our image debugging: should we use 'launch' or 'attach'? Could you please provide some context on what exactly the 'attach' and 'launch' requests are?"

[vadimcn]

Broadly, with "launch", the debugger has control over the creation of the process (such as configuring the debuggee's environment and CLI arguments). With "attach", the process already exists, or someone else decides how it is created. Admittedly, the line gets blurred if you use targetCreateCommands / processCreateCommands; in many cases, you can use either request type.

In the case of remote debugging, I would say that "launch" is appropriate if you use lldb-server platform or gdbserver --multi and create a new process, whereas gdb-remote should use "attach".

The attach request just attaches to a process without changing the process state.

The default LLDB behavior for attach is to pause the debuggee; however, CodeLLDB auto-resumes it unless stopOnEntry is set.
If you use processCreateCommands, your command sequence determines what happens - you can finish it with process continue if you want to keep the process running.

[kiv07]

Thank you so much for your detailed and helpful response.

[kiv07]

Hi @vadimcn ,

pause issue with "request": "launch" has been resolved on codelldb1.11.5, which is very relieving. Thank you for handling this.

On the other hand, I am facing an issue with the "launch" configuration used for starting gdbserver. VS Code is throwing an error window saying that the "process is not valid"(which is from the latest code where the process state is_alive is being checked in the launch.rs file)