With multiple real target launches, debug operation changes call stack selection

[vinodappuvmw]

I'm testing using two debug launches (Real hardware debugging) in windows, cdt-gdb-vscode v0.0.108 is used. When continuously stepping on one launch, with other launch suspended, the call stack suddenly switches to suspended launch. If I continue stepping, the second launch is being stepped.

This is a wired behavior. Please let me guide on where to be focused to fix the issue.

Note : Issue is not reproducible with local debugging (Tried using amalgamator workspace https://github.com/eclipse-cdt-cloud/cdt-amalgamator )

@jonahgraham @MatthewKhouzam @thegecko @marco-miller

[jonahgraham]

You can provide a trace of the debug session, e.g. verbose = true, optionally putting it in a file:

cdt-gdb-vscode/package.json

Lines 110 to 118 in 36449f8

	"verbose": {
	"type": "boolean",
	"description": "Produce verbose log output",
	"default": false
	},
	"logFile": {
	"type": "string",
	"description": "Absolute path to the file to log interaction with gdb"
	},

Are you stepping on the step button next to the process you want to step, but the other one is stepping? I would look in the adapter log to see if the adapter is interpretting the input wrong, or if VSCode is sending an unexpected thread id. If the former, the bug is in the adapter and if the latter it is a vscode issue.

[vinodappu]

How can I see gdb trace? Any option in settings? I don't see any option when I checked. If I need to rebuild extension again, then it'll not help if I deployed it. Please guide.

[colin-grant-work]

When you set "verbose": true as @jonahgraham suggested, then you can see the data in the Debug Console:

launch.json:

Open Debug Console:

See all traffic between CDT-GDB Adapter and GDB:

When you initially encountered the problem, were you using the CDT GDB Amalgamator for debugging, or were the two sessions represented as separate debug sessions to VSCode?