Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] [Major Bug?] CDT creates GDB variables but does not delete them

Sascha Radike wrote:


I'm gonna raise a bug if no one has a solution for this. To me this is major
as it has negative impact on remote/embedded debugging and could be seen as
a kind of "memory leak":

CDT creates GDB variables for expressions, registers, etc. to evaluate them.

I added the following watch expression "*(unsigned int*) 0x201234" in the
expressions view.

Verbose example:

3245-var-create - * "*(unsigned int*) 0x201234"
3245^done,name="var92",numchild="0",type="unsigned int"
(gdb) 3246-var-evaluate-expression var92

[This causes GDB to read 4 bytes at 0x201234]

Alright. CDT does not delete var92. Now I resume until I hit a breakpoint

Verbose after halt:

3253-var-update var92

[This causes GDB to read 4 bytes at 0x201234]

But now CDT creates another variable for the watch expression !

3256-var-create - * "*(unsigned int*) 0x201234"
3256^done,name="var93",numchild="0",type="unsigned int"
(gdb) 3257-var-evaluate-expression var93

[This causes GDB to read 4 bytes at 0x201234]

So this time GDB already has to read 8 bytes in total (twice the same

If I resume again and hit the next breakpoint (or interrupt) CDT will create
ANOTHER variable "var94" and GDB will read 12 bytes.

To sum it up: Every time the target halts, CDT creates a new variable for
every watch expression (and maybe other stuff, too - I don't see any delete)
"-var-create" and updates its previous variables "-var-update". So with
every halt CDT forces GDB to read more memory (4, 8, 12, 16, 20, 24, 28,
...) - every time the same address.

You maybe don't notice this on a local machine. But if you debug a remote
target you will sooner or later notice a slow down.

Even worse: After deleting my watch expression "*(unsigned int*) 0x201234"
CDT still updates its previous variables ("-var-update" which it has created
for that expression. So even if the watch expression does not exist any more
GDB will  still read the memory.

Eclipse RC7 + CDT 3.2 HEAD (1-2 weeks ago or so)


cdt-dev mailing list

Hi Sascha,

Did you find a solution for this problem or did you raise a bug.
It seems we face the same problem with one of our Eclipse toolset.


Back to the top