Not all GDB errors are shown in the debug console?

[GitMensch]

I've wondered why a launch configuration did not work, and only after "openGdbConsole": true, was enabled I've seen it there: "symbol lookup error: undefined symbol" (there was a bad .so in LD_LIBRARY_PATH).

Any idea why this was not reported by the debug adapter to the ui?`

To client: {"seq":0,"type":"response","request_seq":2,"command":"launch","success":true}
From client: setFunctionBreakpoints({"breakpoints":[]})
GDB command: 5 -break-list
GDB result: 5 done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}
To client: {"seq":0,"type":"response","request_seq":3,"command":"setFunctionBreakpoints","success":true,"body":{"breakpoints":[]}}
From client: setExceptionBreakpoints({"filters":[]})
To client: {"seq":0,"type":"response","request_seq":4,"command":"setExceptionBreakpoints","success":true}
From client: configurationDone({})
GDB command: 6 -exec-run
GDB notify async: thread-group-started,id="i1",pid="23213"
GDB notify async: thread-created,id="1",group-id="i1"
GDB notify async: 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="0x00007ffff7fd3090",to="0x00007ffff7ff22a0"}]
GDB result: 6 running
GDB exec async: running,thread-id="all"
To client: {"seq":0,"type":"response","request_seq":5,"command":"configurationDone","success":true}
From client: threads({})
To client: {"seq":0,"type":"response","request_seq":6,"command":"threads","success":true,"body":{"threads":[{"id":1,"name":"1","running":true}]}}
To client: {"seq":0,"type":"event","event":"output","body":{"category":"stdout","output":"[Inferior 1 (process 23213) exited with code 0177]\n"}}
[Inferior 1 (process 23213) exited with code 0177]
GDB notify async: thread-exited,id="1",group-id="i1"
GDB notify async: thread-group-exited,id="i1",exit-code="0177"
GDB exec async: stopped,reason="exited",exit-code="0177"
From client: stackTrace({"startFrame":0,"levels":20,"threadId":1})
GDB command: 7 -stack-info-depth --thread 1 100
GDB result: 7 error,msg="Thread id: 1 has terminated"
To client: {"seq":0,"type":"response","request_seq":7,"command":"stackTrace","success":false,"message":"Thread id: 1 has terminated","body":{"error":{"id":1,"format":"Thread id: 1 has terminated","showUser":true}}}

[jonahgraham]

IIUC the error message appeared in the CLI output and all the MI side was only informed that the inferior had terminated? If so, that is a question for GDB folk I guess? (But I know you do a lot of stuff on GDB, so perhaps I am misunderstanding the issue?)

[GitMensch]

IIUC the error message appeared in the CLI output and all the MI side was only informed that the inferior had terminated?

Yes.

If so, that is a question for GDB folk I guess?

Possibly both "GDB folk" and "debug adapter".

The issue from the debug adapter site is that cli output is not handled if "openGdbConsole": false is set, but should.
Other extensions will then show the output in the debug console (detailed when verbose, otherwise only the actual stdout and stderr/undefined messages - the later is currently missing in the extension and not shown in the log at all).

But yes: there should be a MI message and rechecking shows - there isn't one. I guess I'll need to build GDB 13 (or at least the last release 12) and recheck there, and report it otherwise.

[jonahgraham]

Thanks for the clarification. Let me see what I can do about the "openGdbConsole": false case.

[jonahgraham]

Can you send the DAP + MI trace when "openGdbConsole": false? Alternatively how to make such a broken executable that you described in OP?

If I do the simple case of passing in an invalid program I get an expected pop-up:

[jonahgraham]

The screenshot above has a testcase to verify it:

cdt-gdb-adapter/src/integration-tests/launch.spec.ts

Line 44 in 49a5683

it('reports an error when specifying a non-existent binary', async function () {

I will have a read through the code to see why other error messages might be muted.

[GitMensch]

how to make such a broken executable that you described in OP?

• create libsome with exported function "a"
• create libsomeB with exported function "b"
• create a.out linking against libsome for function "a"
• debug a.out - all is fine
• rename libsomeB to libsomeA
• debug a.out - see the error

The "common" real-world example is a library that was linked with version 123 but used with version 120.

[GitMensch]

The screenshot above has a testcase to verify it

That works because there is an async result record for the "file-exec-and-symbols" request (output from another client, but identical here):

{"token":2,"outOfBandRecord":[],"resultRecords":{"resultClass":"error","results":[["msg","/tmp/not/there: No such file or directory."]]}}

(note: that's a local gdb, not gdbserver with "No such file or directory.", so the comments in the referenced code are at least misleading)

if a linked shared library has a mismatch you get:

{"token":2,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}

And also a positive result for exec-run and only after both an stderr message (not a failure), likely from the dynamic link loader.
The only "direct" result GDB sends is a console output with the "Inferior ... exited", followed by notify events thread-exited + thread-group-exited, followed by "stopped" return.

The code you've linked is likely "finished" there already.

[jonahgraham]

See #241 for what I created as you outlined in #239 (comment)

[jonahgraham]

The test case I added in #241 sends the error to the inferior's stderr, so it is completely lost by cdt-gdb-adapter, but would be improved by having #161 fixed properly.

For now with no proper inferior, the stderr of the inferior disappear to nothing as the spawned process's stderr is never read:

cdt-gdb-adapter/src/GDBBackend.ts

Lines 81 to 87 in c653a9a

	this.proc = spawn(gdbPath, args);
	if (this.proc.stdin == null || this.proc.stdout == null) {
	throw new Error('Spawned GDB does not have stdout or stdin');
	}
	this.out = this.proc.stdin;
	this.hardwareBreakpoint = requestArgs.hardwareBreakpoint ? true : false;
	await this.parser.parse(this.proc.stdout);

[jonahgraham]

In the immediate term I am going to start capturing stderr and returning that to the client.