GDB session ended. but the debug toolbar won't close. #1029
Comments
See, you did not do that, so I have nothing to look at. Nothing changed on our end in almost six months. Did JLink change? Did you try rolling back a few versions. I really doubt JLink caused an issue but, did you look at what could have gone wrong? The toolbar does not change state because VSCode (it controls that toolbar) thinks the debugger is still running. You also did not say what you did to get the debugger into this state. How am I supposed to reproduce/debug this? I'm closing this until you give me a better description. |
|
Adding some info here, experiencing the same issue since the last update (probably with 1.12, but not 100% sure). Replication of the issue is easy:
See debug info: |
@RolfNoot , that indicates a crash in JS code. If you click on that popup, you may see more info on the source or the problem. In your system temp directory (indicated by $TMPDIR on Mac/Linux and %TEMP% env. var on Windows), hopefully in that directory there is a filed called |
|
Please see https://github.com/Marus/cortex-debug/wiki/Cortex-Debug-Under-the-hood on how a typical debugger is put together. |
|
This is the log file This is the output of the Developer Tools console as soon as the server disconnects but the toolbar remains: I am also debugging your extension: Let me know if you need me do check something while debugging, put breakpoints or need anything more |
|
I am on holiday (Independence Day in US). Besides, I don't have a board yet. Expecting one soon. Get back to this later. It is one thing for gdb to exit, but another for us to exit because there is other cleanup that has to occur. It appears that messages are being generated even though the debugger has crashed or destroyed. Need to go up the stack to see what is going on. @RolfNoot Have you read my Wiki page I attached above? Of course, you are the expert! One of the problems is that the Heisenberg principle comes in by putting breakpoints. Especially while ending the session. Your best bet is to put temporary debug messages in suspected areas like I tried to do with the |
|
Hi @haneefdm, Yes, I've read the wiki. I understand the issues you're facing and that it's even harder to pinpoint the eventual error, especially with 'vague' or limited user comments. I always feel that when the issue is to be reproduced, the solution is near. Yes putting breakpoints can confuse even more and may completely break the functionality, especially when dealing with multithreaded designs. I mean if you want me to add anything to the log or help, I am here. We're dealing with users as well and it's not always easy to help especially when there's not much information. I am willing to send you a Onethinx LoRaWAN kit which contains PSoC6 if it may help speed up investigations. Enjoy the free day! |
|
I have a bad feeling about this. It appears that it is VSCode that is totally confused. Over the last 5+ years, the definition and behavior of a 'Restart' kept changing. Maybe it changed again. At one point they did not trigger preLaunchTask on a Restart. Then they did a preLaunchTask. Then reverted back. Then reverted that decision. No idea what else changed with the Restart. The A few years ago, we got tired of this and added a 'Reset' button because....
Thus, the Reset is fast and what most embedded developers wanted. It appears from the logs that we have done everything we are supposed to do for a 'Restart' and Disconnect/Stop. But maybe their expectations changed. Need to focus on 'Restart' because it appears that if this was never called, it seems to work fine. Need to find out how debuggers are supposed to respond to a 'Restart' request. Rarely, documented so we have to do this by trial and error and looking at VSCode source. Perhaps play with cppdbg or some other debugger. |
|
Fixed it. VSCode was seriously messed up. I found many debuggers have removed the 'Restart' functionality from their adapters. Instead, VSCode totally restarts from scratch almost like you did a 'Stop' followed by a 'Start'. Good riddance, because no one knew what the rules were. But, now we have to remove Restart options from the launch.json (our package.json) because a Restart is now handled by VSCode and we have no involvement in it. |
|
Good to hear! I was just close, looking at the differences between 1.4.4 which works and 1.5.0 which doesn't. If you like I can check further to pinpoint the causing issue. |
Confirmed, it works at my side. It is actually re-reading launch.json and applying changes if there are in launch.json. Thanks so much, this issue was bothering me for some time! |
|
Adrii, this may affect you. If you are still working on this, please see https://github.com/Marus/cortex-debug/blob/master/CHANGELOG.md If there are general issues, could you give your feedback here? If you want to chat privately, you have my GitHub handle. |
|
hello, does anyone konw how to fix it? |
|
I tested it with the current master branch, looks good to me as well @haneefdm. I'm not deeply informed about the dev-progress, but seems save to release from my POV. |
Screenshots
Environment (please complete the following information):
[comment]: <> Whenever possible, please make sure you are using the latest versions of VSCode and our extension
Please include
launch.jsonAttach text from
Debug ConsolePlease enable debug output in your launch.json (
"showDevDebugOutput": "raw"). It this is too large, please attach it as a fileThe text was updated successfully, but these errors were encountered: