User forums > Using Code::Blocks

Debugger: Watches in nightlies

<< < (2/2)

Jenna:
Accessing unitialised variables like the most local variables are can lead to a crash, due to a "bug" in gdb, if I remember correctly.

oBFusCATed:
Yes, the problem with designing a good gui stops me from implementing it.
Also the other two problems:
1. It slows down single stepping a lot
2. Can lead to crashes if one is using python pretty printer
*3. There is no easy way for this to  be implemented using the gdb/mi interface as far as I know.
*4. Probably you can hack it by writing something in python which iterates all frame variables and prints them...

1 and 2 make it hardly reliable, nor usable for me.

pitti platsch:
I am with Rosch here. Having C::B not automatically show local variables currently stops me from updating my installation.

Point 1 (slowdown): When the extra "locals/function arguments" window is not visible, there should be no slowdown in single stepping
2: Warn the user when he first tries to open the "locals/function arguments" window, that gdb sucks that this is incompatible with phyton pretty printing. Disable/hide that window by default.
3: I have almost no knowledge about GDB/MI, but http://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Stack-Manipulation.html suggests "-stack-list-locals" and "-stack-list-arguments"

Does this python pretty printing bug mean that GDB could crash whenever I hover over an unitialized variable?

Peter

oBFusCATed:

--- Quote from: pitti platsch on October 29, 2012, 08:25:34 pm ---Does this python pretty printing bug mean that GDB could crash whenever I hover over an unitialized variable?

--- End quote ---
Yes, it could even enter infinite loop, which is worse.

Navigation

[0] Message Index

[*] Previous page