Description:
In the Debug Adapter Protocol's specification for the Stopped event, the threadId is described as "The thread which was stopped." However, I've encountered an inconsistency between the specified threadId and the actual ID of the thread.
To extract the threadId, I use the following code in my extension:
public onDidSendMessage(m: DebugProtocol.ProtocolMessage) {
this.routeDebugMessage(m);
}
private routeDebugMessage(m: DebugProtocol.ProtocolMessage): void {
if (m.type === "event") {
const e = m as DebugProtocol.Event;
switch (e.event) {
case "stopped": {
const threadID = e.body?.threadId as number;
// ... other operations
}
}
}
The C++ code for my breakpoint is:
// ... some code ...
int main(int argc, char *argv[]) {
constexpr size_t length = 32;
// ... other code ...
}
In this context, I received a value of 18888 for threadId instead of the expected 1 as shown by the -exec info threads command:
Id Target Id Frame
* 1 Thread 0x7ffff59b15c0 (LWP 18888) "array-transform" main (argc=..., argv=...) at array-transform.cpp:27
From my observations, it seems that the LWP (Light-Weight Process) value is being used instead of the actual thread ID, leading to potential confusion and issues.
This discrepancy is also visible in the MI log:
1: (3018) <-1019-exec-run
1: (3020) ->=thread-group-started,id="i1",pid="18888"
1: (3020) ->=thread-created,id="1",group-id="i1"
1: (3024) <-1020-thread-info 1
1: (3040) ->=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd0100",to="0x00007ffff7ff2684"}]
1: (3045) ->1019^running
1: (3045) ->*running,thread-id="all"
1: (3045) ->(gdb)
1: (3045) 1019: elapsed time 27
1: (3046) ->~"Stopped due to shared library event (no libraries added or removed)\n"
1: (3046) ->*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="111"
1: (3047) ->(gdb)
1: (3047) ->1020^done,threads=[{id="1",target-id="process 18888",name="array-transform",frame={level="0",addr="0x00007ffff7fd2fd1",func="??",args=[],from="/lib64/ld-linux-x86-64.so.2",arch="i386:x86-64"},thread-group="i1",state="stopped",core="111"}]
1: (3047) ->(gdb)
blablabla
Breakpoint 1, main (argc=..., argv=...) at array-transform.cpp:27
27 constexpr size_t length = 32;
1: (3539) <-1027-thread-info
1: (3540) ->1027^done,threads=[{id="1",target-id="Thread 0x7ffff59b15c0 (LWP 18888)",name="array-transform",frame={level="0",addr="0x0000000000404819",func="main",args=[{name="argc"},{name="argv"}],file="array-transform.cpp",fullname="/home/user/array-transform/src/array-transform.cpp",line="27",arch="i386:x86-64"},thread-group="i1",state="stopped",core="111"}],current-thread-id="1"
1: (3540) ->(gdb)
1: (3541) 1026: elapsed time 35
1: (3543) 1027: elapsed time 4
Expected Behavior:
The threadId in the Stopped event should match the actual thread ID as per the Debug Adapter Protocol's specification.
Actual Behavior:
The threadId in the Stopped event is reflecting the LWP value instead of the actual thread ID.
Additional Context:
The observed behavior can lead to potential issues and confusion, especially when there's a reliance on accurate thread ID values for debugging purposes.
Description:
In the Debug Adapter Protocol's specification for the Stopped event, the threadId is described as "The thread which was stopped." However, I've encountered an inconsistency between the specified threadId and the actual ID of the thread.
To extract the threadId, I use the following code in my extension:
The C++ code for my breakpoint is:
In this context, I received a value of 18888 for threadId instead of the expected 1 as shown by the -exec info threads command:
From my observations, it seems that the LWP (Light-Weight Process) value is being used instead of the actual thread ID, leading to potential confusion and issues.
This discrepancy is also visible in the MI log:
Expected Behavior:
The threadId in the Stopped event should match the actual thread ID as per the Debug Adapter Protocol's specification.
Actual Behavior:
The threadId in the Stopped event is reflecting the LWP value instead of the actual thread ID.
Additional Context:
The observed behavior can lead to potential issues and confusion, especially when there's a reliance on accurate thread ID values for debugging purposes.