search

WebFreak001 / code-debug

Native debugging for VSCode
The Unlicense
409 stars 115 forks source link

Debugging Zephyr app on reel board with GDB TUI see some python error. #311

Open smrtos opened 2 years ago

smrtos commented 2 years ago

For details: https://github.com/pyocd/pyOCD/issues/1324

Not sure if this should be fixed on the PyOCD side or here. Could you take a look? Thanks!

GitMensch commented 2 years ago

How is this extension related to GDB TUI?

The exception you see is related to this extension's exception handling. Please post your launch configuration along with the full debugging log of your connection (as text) and we can have a look at what is actually happening.

smrtos commented 2 years ago

Yes, it's has been addressed here: https://github.com/cyrus-and/gdb-dashboard/issues/259 This one can be closed.

BTW, my .gdbinit is this one: https://github.com/cyrus-and/gdb-dashboard/blob/master/.gdbinit

GitMensch commented 2 years ago

The issue here - from the mentions on pyOCD - were exception handling and non-working debug console.

Do I understand it correctly that the (global) gdbinit file has the GDB dashboard - that you actually don't want to use when using this extension? Do I also understand it correctly that because of an issue in the gdbinit file the extension (at least seemed) to not work at all?

GitMensch commented 2 years ago

Out of interest: Does everything work on the extension side when using the "bad" gdbinit file if you add debugger_args: ["-nh"] to your launch configuration?

GitMensch commented 2 years ago

@brownts @WebFreak001: Should we always (or by default) disable use of external gdbinit files or should we only ensure that the documentation points out possible issues with external gdbinit files?

brownts commented 2 years ago

My suggestion would be not to deviate from the "normal" gdb startup without the user knowing. During an issue, we typically ask whether the same behavior can be seen/accomplished via running gdb from the command line. If we start changing the default behavior (i.e., not executing the .gdbinit file) under-the-hood, it may make it more difficult to diagnose or root cause problems.

I would have expected that if the user ran the same command from the command line, they should have seen the same problem, correct?

I'd recommend a documentation-only update, if any update is performed at all.

WebFreak001 commented 2 years ago

native debug works pretty close to the debugger, you even enter raw GDB commands in the debug console (as opposed to other extensions where you type in variable names to examine them) so I think keeping the gdbinit would be better.

GitMensch commented 2 years ago

Agreed. Is there anyone that could add a "Trobuleshooting" note in the README? This can also mention something along:

Native debug works pretty close to the debugger and does not suppress any default initialization. If you use initialization scripts that change the behavior or open tui-mode, this could interfere with any other debug frontend. Therefore, if you see any unexpected behavior or errors, especially during start of debugging sessions, consider to add debugger_args: ["-nh"] to your launch configuration to suppress those external initialization files.

This may be added also to the bug creation template (which I'd really like to see adjusted in any case, there should be no use of tasks inside it).