Community
Participate
Working Groups
Created attachment 287796 [details] project that cannot be debugged Find attached a project that I simply cannot step through (debug mode) with Eclipse 2021-12 (CDT 10.5.0). I have also attached a screenshot taken right after launching the application. The application stops at the main (breakpoint) and on the upper right you should see the list of local variables -- except you don't. It's not there. I cannot step through the program or do anything else meaningful. Even stopping the app fails with some error message. It get's better if I remove a couple of lines from main.cpp (especially the lambda expression). So maybe the lambda is the culprit here? I'm running Eclipse 2021-12 on Arch Linux with all latest updates. GDB version is 11.1 and GCC is 11.1.0.
Created attachment 287797 [details] screenshot of empty Variables view The variables view should show the local variables, but it just shows some ">" marks indicating that there is something to unfold. I can even click the items in the list, but stay empty.
Hmm, it's not related to the lambda expression. I shorted main as follows: int main(int argc, const char * const argv[]) { std::unordered_set<string> features; argparse::ArgumentParser args(argv[0], "", argparse::default_arguments::help); } The problem still occurs.
I can reproduce this GCC 10.3 and GDB 9.2 (the defaults on my Ubuntu 20.04 machine). I can see that GDB has stopped responding (Eclipse is waiting for a response to 337,806 41-var-list-children var3) - this indicates a possible GDB bug. I will try to reduce it further.
Hi Sven, The problem here is in the Python pretty printers that are part of GBD/GCC. They are getting in an infinite loop when trying to calculate the content of the "features" variable in your main. You can work around the problem in one of three ways: 1) Make sure you don't hit a breakpoint before features is populated. You can do this by disabling the automatic breakpoint at main (in the Launch Configuration dialog uncheck "Start on startup" https://imgur.com/Oyq7Jxv.png) and adding a breakpoint a bit later in the code. 2) Disable the pretty printers. In preferences -> C/C++ -> Debug -> GDB uncheck Enable pretty printers: https://imgur.com/H1PyYno.png 3) Sending SIGINT to GDB to force the a KeyboardException in the Python code (e.g. killall -s SIGINT gdb). You may want to turn on the Show GDB Traces so you can see the command that is stuck: https://imgur.com/H1PyYno.png Please submit a bug to GDB or GCC to get the underlying bug resolved. Eclipse CDT could do better here by offering to user to abort the stuck command in GDB. In my experiments SIGINTing seems to bring things back to life, however at the time of the SIGINT Python returns huge quantity of data which CDT pauses slightly while processing as well. To reproduce at the command line (useful for submitting bug to GDB/GCC): Build project and start GDB in MI mode: $ gdb --interpreter=mi2 nameofexecutable Then run these commands to setup GDB: 1-enable-pretty-printing 2-gdb-set print object on b main run Then run these commands to cause GDB to hang in the Python side: 3-var-create --thread 1 --frame 0 - * features 4-var-list-children var1 If you then SIGINT GDB you (normally) get output like this: ^C&"Python Exception <class 'KeyboardInterrupt'> <class 'KeyboardInterrupt'>: \n" 4^done,numchild="34936",children=[child={name="var1.[0]",exp="[0]",numchild="0",type="std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >",thread-id="1",displayhint="string",dynamic="1"},child={name="var1.[1]",exp="[1]",numchild="0",type="std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> [... continues for a long time, depending on how quickly SIGINT was done)
