Eclipse Community Forums: C / C++ IDE (CDT) » GDB debug very slow with big variables

Home » Language IDEs » C / C++ IDE (CDT) » GDB debug very slow with big variables

GDB debug very slow with big variables [message #1767833]

Tue, 11 July 2017 09:07

Eclipse User

Hi everyone,

I have the issue that debugging with GDB in eclipse CDT gets extremely slow when large lists/variables/vectors are involved. When I hover over a large variable or have the "Variables" view open it takes sometimes 5-10 minutes to show the values.
In that time I can not continue stepping through the program.

When the variables are shown finally and I step forward I have to wait again more than 5 minutes until it shows the updated variables. I tried everything I found on the internet to speed up, but nothing worked.
Please see my eclipse GDB config below.

I'm running ubuntu 14.04 with Eclipse Oxygen and GDB 7.7.1.

I activated the GDB traces view and it gets stuck at

805,391 (gdb) 
805,398 103-stack-list-locals --thread 1 --frame 0 1
805,400 104-stack-list-frames --thread 1

before finally showing the content of the huge variables and then:

219,344 (gdb) 
219,345 104^done,stack=[frame={level="0",addr="0x00000000004072b0",func="sfm_reconstruct",file="sfmr\
econ.cc",fullname="/home/john/development/mve/apps/sfmrecon/sfmrecon.cc",line="233"},frame={level\
="1",addr="0x0000000000409d3a",func="main",file="sfmrecon.cc",fullname="/home/john/development/mv\
e/apps/sfmrecon/sfmrecon.cc",line="635"}]
219,345 (gdb)

When debugging with GDB in the terminal and print "p bigVariable" it shows immediately only a small fraction without any delay. Then I can show more or quit showing the variable. I think that must also be possible with Eclipse, otherwise I can't debug big programs with Eclipse.

Do you have any idea how can I configure Eclipse/GDB to show only a fraction of the variables??? The config below doesn't seem to work though. I am quite desperate at the moment.

Thank you very much,
John

index.php/fa/29928/0/

Attachment: Selection_045.png
(Size: 122.15KB, Downloaded 5051 times)

Re: GDB debug very slow with big variables [message #1767895 is a reply to message #1767833]

Wed, 12 July 2017 00:57

Eclipse User

Use the Expressions view to get only the variables of interest.
Avoid hovering over large variables or disable debug hovers,
i.e., uncheck Window --> Preferences --> C/C++ --> Editor --> Hovers --> Debugger

Re: GDB debug very slow with big variables [message #1767924 is a reply to message #1767833]

Wed, 12 July 2017 04:18

Eclipse User

Hi David,

thanks for your reply.
That was a great suggestion, now we get closer to the real problem.
I did what you said.

The big variable is called "viewports" which is a vector of class "viewport", with 998 elements with each quite some nested more objects.
I add viewports to the expressions and click only on the expand arrow. It lists only the first 5 elements, everything is fine.
But as soon as I collapse the viewports it selects the variable itself and GDB issues the "data-evaluate-expression --thread 1 --frame 0 viewports", which then takes around 5 minutes. GDB runs with 100% CPU on one core and then returns the result to eclipse which lists ALL contents of "viewports" in the gdb traces.
This results in a weird overlapping display in the expressions tab, see the screenshot below.

I attached the gdb traces as txt-file for you to see where is the problem.
The problematic command is 144.
In the beginning of the file it says it cannot find .gdbinit and it shows other gdb settings.

EDIT:
I read a .gdbinit file is not necessary.
Even when right-clicking on "viewports" it immediately issues the data-evaluate-expression command.

Thank you very much,
John

index.php/fa/29942/0/

Attachment: Selection_046.png
(Size: 33.31KB, Downloaded 4897 times)
Attachment: gdb_traces
(Size: 4.95MB, Downloaded 329 times)

[Updated on: Wed, 12 July 2017 04:27] by Moderator

Re: GDB debug very slow with big variables [message #1767928 is a reply to message #1767924]

Wed, 12 July 2017 04:31

Eclipse User

Hi,

The data-evaluate-expression comes from the details pane in the Experessions view.

Try turning it off, press the down facing triangle --> Layout --> Expressions View Only

index.php/fa/29945/0/

That said, the results you are getting here are not good (i.e. you should not have to be crippling the IDE). But I don't know where to start on this. Can GDB's data-evaluate-expression be cancelled and/or time limited? If that functionality is not already in place, I suspect that GDB is going to need to be enhanced before CDT will be able to deal with this properly.

Does your UI stay responsive through this 5 minutes?

Attachment: expressions.png
(Size: 28.94KB, Downloaded 4874 times)

Re: GDB debug very slow with big variables [message #1767951 is a reply to message #1767928]

Wed, 12 July 2017 07:04

Eclipse User

Hi,

the "Expressions View only" settings actually solved my problem, or at least I can debug properly now with this workaround without having to wait 5 minutes for each debugging step.

When I click on any variable in the Expressions view it does not issue any command now.

However there is still one problem:
Hovering is still activated somehow and issues the data-evaluate-expression for all variables when hovering over them.
- "Use enhanced debug hover" in the GDB settings is disabled
- "Editor->Hovers->Debugger" is also disabled, as David suggested
There seems to be no project specific setting for hovering.
Any other hover settings I have to change? I also restarted Eclipse already.

@Jonah
If the data-evaluate-expression can be cancelled is a good question. I don't see a way to interact with the GDB session through the console. I also don't know if there is a possibility to time-limit the GDB execution.
I guess the CDT UI must somehow generate the command and send it to the GDB session. Issuing the data-evaluate-expression command for the whole variable might not be a good idea for big lists.
The CDT UI stays responsive while Eclipse waits for the result of the GDB command.
However, I can not continue stepping when the result of the data-evaluate is not there by that time.

Re: GDB debug very slow with big variables [message #1767954 is a reply to message #1767951]

Wed, 12 July 2017 07:33

Eclipse User

Hi John,
Quote:

If the data-evaluate-expression can be cancelled is a good question. I don't see a way to interact with the GDB session through the console. I also don't know if there is a possibility to time-limit the GDB execution.
I guess the CDT UI must somehow generate the command and send it to the GDB session. Issuing the data-evaluate-expression command for the whole variable might not be a good idea for big lists.
The CDT UI stays responsive while Eclipse waits for the result of the GDB command.
However, I can not continue stepping when the result of the data-evaluate is not there by that time.

Thanks for the confirmation on all these points. CDT should not be issuing commands that take (essentially) forever for GDB to resolve, but I think that CDT does not have a way of knowing that this data-evaluate-expression is going to take longer than any other one. If you know of a way to handle it, I am all for that.

There may be another way to resolve the issue here, and that is with Python's handlers for such things. Can you file a bug https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CDT so that we can track this issue.

Quote:

Any other hover settings I have to change? I also restarted Eclipse already.

Not 100% sure, but you probably need to turn off C/C++ -> Editor -> Hovers -> Combined Hover too.

Re: GDB debug very slow with big variables [message #1767998 is a reply to message #1767954]

Wed, 12 July 2017 11:36

Eclipse User

Hi Jonah,

I filed a bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=519561

Disabling C/C++ -> Editor -> Hovers -> Combined Hover resolved the hover issue for me.

So the current workaround for me that works:
Closing "Variables" view, having "Expressions" view open with "Expressions Only View" enabled and disabling any hovering enables me to debug big vectors while being quite speedy.

Having the "Variables" view open issues the GDB commands "stack-list-locals" and "stack-list-frames" which results in minutes of waiting per debugging step.
To solve this the GDB commands/arguments need to be modified or other commands issued instead which don't return a listing of all the contents of the variables (which are not shown in the first place to the user anyway).

I am not a GDB expert unfortunately, so I can't come up with commands or arguments to have a quick fix on this.

[Updated on: Wed, 12 July 2017 11:41] by Moderator

Re: GDB debug very slow with big variables [message #1768033 is a reply to message #1767998]

Thu, 13 July 2017 03:08

Eclipse User

Thanks John for a detailed report.

Re: GDB debug very slow with big variables [message #1768041 is a reply to message #1768033]

Thu, 13 July 2017 04:06

Eclipse User

Thank you too David and Jonah for the suggestions of the workaround.

I suppose this topic is transitioning to the bug report now.

I am just wondering that apparently nobody else has ever had this problem, either because barely anyone has to debug programs with that big lists or people gave up debugging when the data became too large.
The structure of the problematic big vector can be taken from the GDB traces in the bug report. I bet when creating a similar structure with similar elements the issue should be reproducible.

Re: GDB debug very slow with big variables [message #1771972 is a reply to message #1767833]

Fri, 01 September 2017 18:37

Eclipse User

First, I would like to thank everyone for their efforts to diagnose and resolve these problems.

I have also had very serious Eclipse (Oxygen/CDT 4.7.0) problems with GDB. Single-step performance (F5/F6) has been terrible (several seconds per step with 100% GDB CPU usage). My GDB version is 8.0.

I was able to get around these problems in a trivial way that actually worked. I clicked on the Breakpoints tab and made sure that the Variables tab was in the background. This absurdly simple change improved performance drastically.

Previous Topic:	project error after migration from eclipse kepler to neon/and oxygen
Next Topic:	Unable to build project

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Mar 21 10:29:37 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter