-
Notifications
You must be signed in to change notification settings - Fork 238
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
Debugging not working anymore/GDB not starting since pre-release version 1.3.2 #598
Comments
Hmmm. Are you able to manually run that same command?
Wonder how large the output is. Even if nm crashes, we can still continue with debug. If the debug control bar disappeared, then the debugger backend (the program that talks to gdb) itself crashed. |
Ohh, and this command too
|
Would it be possible for you to try the most recent as of now is 1.3.4 pre-release. I don't think we changed anything that should affect how you are using this with WSL. Both nm and objdump can crash and burn but you should still be able to debug (minus a few features). What did change was how we added some code in case if the server or gdb crashes or disconnects unexpectedly. In what you reported above, it appears that gdb didn't even start or we crashed even before gdb started |
.txt file generated by nm is 174 KB and 639 lines I just wanted to mention that running the command as you wrote it and like it is printed in the debug console does not work for me, as the toolchain .\bin folder is not in my path variable. Instead i inserted the full-path to the corresponding exe's like i specified in
Yes I've done that, I tried multiple pre-release version from the version-history in VS-Code Marketplace. All I could see is that it worked up to Pre-Release Version 1.3.1. Starting with Pre-Release version 1.3.2 (so also 1.3.3, 1.3.4) it does not work any longer.
Yep, that's what I also thought/guessed |
Wild guess. Could you also set |
I think I am able to duplicate the problem. An invalid objdump path causes a double fault. Was only handling a single fault. |
I just tried and setting Maybe the log message in the debugconsole could state that path not found for nm and objdump if possible, then the user get's some hint where he needs to search/what he needs to fix |
It died while printing an error :-) The two programs were running simultaneously and both errors (exceptions) happened. I just fixed it. Should be in the next pre-release shortly. |
Oh perfect, thanks alot for your work! |
Could you try out a manual build I created for both of your issues. I could not duplicate the RTT issue #599, however. Want to know if this is still an issue. https://github.com/Marus/cortex-debug/releases/tag/v1.3.5-pre1 |
Tried your manual build, for me it works fine. When
|
Hi,
I have an issue since Pre-Release Version 1.3.2, the last version, which worked for me was 1.3.1.
How am I using Cortex-debug?
Maybe this is not the proper way of using Cortex-Debug? However this worked fine so far. I tried different pre-release versions. Up to version 1.3.1 it worked fine, starting with version 1.3.2 I cannot debug anymore. I've also tried to compile & debug directly with windows-toolchain, but this does also not work anymore.
All i get in the debug console, even with "showDevDebugOutput": "both" is:
Afterwards nothing happens. VSCode Debug Bar (where i can halt etc.) disappears.
Has this something to do with the changes in the startup-process mentioned in the changelog of V1.3.2? (objdump and nm).
Thank's in advance for any hints!
The text was updated successfully, but these errors were encountered: