VS Code Version: 1.5.0-insider (4fc690be310dd02e0ab6529c0b9bf348a8b26a19)
C/C++ Extension Version: 0.9.1
OS X Version: 10.11.6 (15G1004)
When trying to debug a process by starting it through the debug pane, I get "Error while trying to enter break state." LLDB exits, and the debug console states my program exited. However, my program continues to run, and I can cmd-tab to it and interact with it as if I had run it without a debugger at all.
Full error plus launch.json at https://gist.github.com/nwgh/dfcd02d4875e966ca6caa1c24a511687
@nwgh Can you confirm that you are compiling your debuggee with the -g flag?
Also, can you try it with a small "Hello World" style app and see if it works or not?
My project has the -g flag and cannot debug. Here's an example:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ \
-DHAVE_BOOST -D_FILE_OFFSET_BITS=64 \
-I/Users/clangen/src/musikcube/src \
-I/Users/clangen/src/musikcube/src/core \
-I/Users/clangen/src/musikcube/src/musikbox \
-I/Users/clangen/src/musikcube/src/3rdparty/include \
-I/Users/clangen/src/musikcube/src/contrib/taglib_plugin/taglib-1.11/stage/include \
-std=c++11 -fpermissive -g \
-o CMakeFiles/musikbox.dir/Main.cpp.o \
-c /Users/clangen/src/musikcube/src/musikbox/Main.cpp
@pieandcakes Yes, my compile flags include -g (I've updated the gist, as the compile flags for my projects are rather large).
I tried a simpler program (also in the updated gist), and that seemed to debug fine - I set a breakpoint at line 9, and it all worked.
This latest attempt was with code 1.6.0-insider (52bceb1207188ecfe8c5b1fbe841b60df512a08a) which still fails to debug a locally-built firefox, though with a slightly different error from in the gist (nothing about LLDB exiting unexpectedly, and it says the debuggee exited with code 42 instead of -1)
Would either of you be willing to send me a repro project? You can email it to me at [email protected]
Also, can you attach an engine log for me? To enable engine logging, please follow these steps:
~/.vscode/extensions/ms-vscode.cpptools-0.9.1. For the insiders build, please replace .vscode in the path with .vscode-insiders"program": "./debugAdapters/OpenDebugAD7",
"args": [
"--engineLogging=<path>"
],
"aiKey": "AIF-d9b70cd4-b9f9-4d70-929b-a071c400b217",
Where
Thanks
Pierson
@pieandcakes emailed the debug log, and also sample project information to your address listed above.
Thanks. Let me set it up and debug it and see whats wrong.
@clangen @nwgh There was a bug that was fixed in mainline lldb. I have released an update to lldb, but it will require you to uninstall and reinstall the extension. Can you try that and see if it fixes this problem for you?
Thanks
Pierson
@pieandcakes awesome! So far, pretty good. The only oddity was that I had to manually kill -CONT the program I was debugging (I sat there waiting for a good long while before realizing the process was probably suspended), but once I did that, things seem to be working great (hit my breakpoint, am able to inspect variables, etc). Thanks!
@nwgh is that every time or just once? Usually when you hit the stop button it should kill the debuggee too unless you are attaching.
@pieandcakes happened while the debuggee was starting up (no window had shown yet). I did the kill -CONT <pid> from the terminal, not from any buttons the code UI. Once I did that, things carried on great.
However, I just tried again, and things seem to have gone a bit farther off the rails (maybe I waited too long to CONT the process?)
This time, while waiting to see if I could just wait longer for the process to keep going, I got
ERROR: Exception while processing MIEngine operation. Unrecognized format of field "msg" in result: result-class: error
message: error: Failed to halt process: Halt timed out. State = stopped. If the problem continues restart debugging.
in the debug console, and once I stopped debugging through the UI, I now appear to have an unkillable (and uncontinuable!) process of my debuggee just sitting there on my machine.
After rebooting my mac to get rid of the totally zombified debuggee, I have now tried a few more times, and every time (assuming I kill -CONT <pid of debuggee> from the cli at the right time), debugging works perfectly (modulo that suspended debuggee).
@pieandcakes - would you like me to get another log of what happens in the extension during that suspended debuggee process?
I'll also try directly in lldb on the command line and see if it's something funky about debugging firefox (haven't had this problem in the past with lldb on the command line, but perhaps things have changed recently).
@nwgh This seems different than the reported issue here. Can you file a new issue with repro steps and i'll see if i can duplicate that and send me an updated log (or attach it to the issue)? I would probably need to set it up on my machine to investigate what is happening.
@pieandcakes this fixed the problem on my end. thank you!
@pieandcakes have to step out for the afternoon, but will do on Monday. And thanks for all your work here!
I have faced this similar issue
Python along with LLDB attach
Gives this exception
ERROR: Exception while processing MIEngine operation. Unrecognized format of field "msg" in result: result-class: error
message: error: Failed to halt process: Process is not running. If the problem continues restart debugging.
Tried to use kill -9 <PID>
But the PID still remains (zombie process)
How to solve this?
@ChaiBapchya Which PID are you trying to kill? We spawn a copy of mono which launches our debugadapter which then launches lldb. See if you have mono.osx running and kill the PID of that process.
Hi @pieandcakes , any chance you can just make a youtube video and screen record how to set up debugging for C++? lol
@Merg12 I've asked our Program Manager if that is possible. I haven't heard back yet but I'll let you know.
Most helpful comment
@nwgh Can you confirm that you are compiling your debuggee with the -g flag?