-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not all GDB errors are shown in the debug console? #239
Comments
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?) |
Yes.
Possibly both "GDB folk" and "debug adapter". The issue from the debug adapter site is that cli output is not handled if 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. |
Thanks for the clarification. Let me see what I can do about the |
The screenshot above has a testcase to verify it:
I will have a read through the code to see why other error messages might be muted. |
The "common" real-world example is a library that was linked with version 123 but used with version 120. |
That works because there is an async result record for the "file-exec-and-symbols" request (output from another client, but identical here):
(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:
And also a positive result for The code you've linked is likely "finished" there already. |
This is based on the usecase described in eclipse-cdt-cloud#239 and will form the basis of a test to make sure we don't lose such error messages. To show the error in GDB outside of the adapter, do this: ```sh $ make BrokenSO gcc -shared -o libsomea.so -fPIC -g3 BrokenSO_libsomea.c gcc -shared -o libsomeb.so -fPIC -g3 BrokenSO_libsomeb.c gcc -o BrokenSO BrokenSO_main.c -g3 -L. -lsomea mv libsomeb.so libsomea.so $ LD_LIBRARY_PATH=$PWD gdb --quiet BrokenSO Reading symbols from BrokenSO... (gdb) b main Breakpoint 1 at 0x1151: file BrokenSO_main.c, line 4. (gdb) r Starting program: /scratch/debug/git/cdt-gdb-adapter/src/integration-tests/test-programs/BrokenSO /scratch/debug/git/cdt-gdb-adapter/src/integration-tests/test-programs/BrokenSO: symbol lookup error: /scratch/debug/git/cdt-gdb-adapter/src/integration-tests/test-programs/BrokenSO: undefined symbol: a [Inferior 1 (process 212237) exited with code 0177] (gdb) ```
See #241 for what I created as you outlined in #239 (comment) |
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
|
In the immediate term I am going to start capturing stderr and returning that to the client. |
The code used to do this.once('output') in a tight loop, but this meant that between processing one of the iterations and the next iteration of the loop a message may have been output. Instead use this.on('output') so all messages are processed. Prerequiste for eclipse-cdt-cloud#239 which generates multiple events quickly
The code used to do this.once('output') in a tight loop, but this meant that between processing one of the iterations and the next iteration of the loop a message may have been output. Instead use this.on('output') so all messages are processed. Prerequisite for eclipse-cdt-cloud#239 which generates multiple events quickly
The code used to do this.once('output') in a tight loop, but this meant that between processing one of the iterations and the next iteration of the loop a message may have been output. Instead use this.on('output') so all messages are processed. Prerequisite for eclipse-cdt-cloud#239 which generates multiple events quickly
The code used to do this.once('output') in a tight loop, but this meant that between processing one of the iterations and the next iteration of the loop a message may have been output. Instead use this.on('output') so all messages are processed. Prerequisite for #239 which generates multiple events quickly
With the stderr captured and sent as OutputEvent this issue is now resolved, however somewhat unsatisfactorily as buffering, and intermixing of outputs with gdb itself, means that it is brittle. #161 will fix this in a better way. |
Well done. As there's no way to update the built-in extension (which isn't rebuild and ci-published as vsix either) I can't test this now. To make this complete: would you mind sharing the output when starting this with the "wrong" libsome in the debugger, both with and without verbose mode enabled? |
verbose off full contents of debug console
verbose on full contents of debug console
openGdbConsole full contents of debug console
full contents of terminal window
|
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?`
The text was updated successfully, but these errors were encountered: