Community
Participate
Working Groups
Created attachment 269330 [details] GDB traces and screenshot Overview short: The main issues with deep-nested big vectors (>1000 elements) are: - with open view "Variables" results in the GDB command "stack-list-frames --thread 1" or "stack-list-locals --thread 1 --frame 0 1" to be issued, taking minutes to return - with open view "Expressions" and clicking on the big vector the GDB command "data-evaluate-expression --thread 1 --frame 0 bigVector" gets issued, taking minutes to return Overview detailed: From Eclipse CDT forum discussion: https://www.eclipse.org/forums/index.php?t=msg&th=1087399&goto=1767928 Debugging with GDB in Eclipse CDT gets extremely slow when large lists/variables/vectors are involved. When hovering over a large variable or having the "Variables" view open it takes sometimes 5-10 minutes to show the values. In that time stepping through the program can not be continued, the CDT UI remains responsive though. When the variables are shown finally and one further debugging step is issued, it takes again very long (e.g. 5 mins) before the updated content is available. After big lists/vector variables have been created it gets stuck at the GDB command: "stack-list-frames --thread 1" before finally returning with the result after 5 minutes. As workaround the "Variables" view can be closed and only the big variable added to the "Expressions" view. When the "Expressions View Only" in the layout settings is disabled and the big variable is selected, GDB issues the "data-evaluate-expression --thread 1 --frame 0 bigVector" command which then takes quite some minutes to return. Then it shows ALL the content of the whole vector in the GDB traces. This produces a weird display as can be seen in the attached screenshot. To fix this, "Expressions View Only" can be enabled. After this the data-evaluate-expression command is no longer issued when selecting the big vectors. Steps to Reproduce: 1. create any deep-nested vector with a lot of objects inside (>1000 in upper level). 2. start debugging session 3. leave "Variables" view open, run to the breakpoint when the deep vector has been created OR 3. open "Expressions" view with "Expressions View Only" disabled and select the big nested vector Actual Results: When debugging a program with large variables, e.g. deep-nested vectors, the "Variables" view takes a long time to load (many minutes). With "Expressions" view open and "Expressions View Only" disabled it also takes many minutes before showing a weird result (see attachment). Expected Results: Fluent debugging despite big variables, without having to change CDT configs. Build Date & Hardware: Ubuntu 14.04 with Eclipse Oxygen 4.7.0 RC2 and GDB 7.7.1. Additional Information: Attached GDB traces with "Expressions" open and "Expressions View Only" disabled. Critical command is 144, taking some minutes to return. Fix suggestion: - Do not issue GDB commands stack-list-frame or data-evaluate-expression for big variables - time-limit GDB execution time to ensure debugging responsiveness (fast debugging experience) - cancel GDB execution if taking too long - use GDB commands that do not list the whole content of vectors
Thanks John for the detailed report including all the analysis. Can you provide a reproducible test case/c++ file the experiences the problem?
I will check if I can make a minimal sample program.
(In reply to John Cooper from comment #2) > I will check if I can make a minimal sample program. Thanks! There is a related issue that has had some recent discussion on SO: https://stackoverflow.com/a/45988312/2796832
Oh yeah, that seems to be a similar problem. I also created a sample with shortened productive code and real data. Here are the steps to reproduce: 1. Get Ubuntu 14.04 (might also work with other versions); I tested in a bare VirtualBox 1. Download the c++ code from here: https://www.file-upload.net/download-12699969/mve.zip.html Careful with the ads, this site seems to love it. Sometimes have to click twice on "Download" for the file to download. 2. Download the data binary file from here: https://www.file-upload.net/download-12699975/prebundle.sfm.html 3. make sure to have the following packages installed or run: sudo apt-get install libjpeg-dev libpng++-dev libtiff5-dev freeglut3-dev libfontconfig1 build-essential 4. change to the "mve" directory and issue "make" or "make -j" 5. Import the directory "mve" as "Existing Eclipse project" in Eclipse (e.g. Oxygen). 6. Create a Debug config for the program in mve/apps/sfmrecon/sfmrecon with the absolute path to the prebundle.sfm file as argument. 7. Start debugging until the first line of cout << "test". You will see that the "Variables" tab stays italic for quite some time, in my case a couple of minutes. To debug the following cout-lines it will issue the heavy GDB commands in every line. You can open the GDB traces console to see the commands issued.
The problem persists with CDT 9.10 and gdb 8.1 on Ubuntu 18.04. gdb hits 100% CPU and it takes very long until Eclipse gets responsive or gdb just terminates. Only workaround: hide Variables view (to avoid that CDT sends command "stack-list-locals") and do not hover over certain variables
