Show local variables in the debugger

[alexchen]

How do I get the debugger to show local variables?  I can only find a debugger 'watch' window that allows me to enter a variable in a function to see its content.  But I cannot find any other way to have the debugger automatically fills in all local variables in a function, or the content of 'this' in a class method when execution steps into the function.

[oBFusCATed]

You can't find it because it is not available at the moment...

[alexchen]

Is there is timetable when this functionality will be available?  This is a very important feature supported by Windows Visual Studio, MacOS Xcode, and Eclipse C++.  It makes life so much easier to debug at source code level.

[MortenMacFly]

Is there is timetable when this functionality will be available?  This is a very important feature supported by Windows Visual Studio, MacOS Xcode, and Eclipse C++.  It makes life so much easier to debug at source code level.

I think I posted a patch that restores this functionality some times back to this forums. You could apply it yourself.

[oBFusCATed]

Is there is timetable when this functionality will be available?  This is a very important feature supported by Windows Visual Studio, MacOS Xcode, and Eclipse C++.  It makes life so much easier to debug at source code level.

No

[alexchen]

Is there is timetable when this functionality will be available?  This is a very important feature supported by Windows Visual Studio, MacOS Xcode, and Eclipse C++.  It makes life so much easier to debug at source code level.

I think I posted a patch that restores this functionality some times back to this forums. You could apply it yourself.

Where can I find the patch?  I assume it requires a rebuild of Codeblocks from source?

[MortenMacFly]

Where can I find the patch?  I assume it requires a rebuild of Codeblocks from source?

For the original version, please search the forums.

However, I believe meanwhile its outdated as we continued work in trunk. So I need to update it anyways. So please stay tuned... I'll post here.

And yes, it requires you to self-compile C::B which is easy.

[alexchen]

Thank you sooooo much!  This will be a life saver to anyone who is serious in source code level debugging.

[oBFusCATed]

This will be a life saver to anyone who is serious in source code level debugging.

I doubt it, in the current implementation this will cause only slowness and random crashes...

[alexchen]

At least we have something to work on.  Bugs can be fixed, but lack of functionality needed for a debugger to be useful will cripple the IDE and render it an editor and code compiler, not a debugger.  I was frustrated by lack of local variable display window I ended up using gdb directly.  Although it is not better but at lease I can go very low level and get the work done.

[Jenna]

At least we have something to work on.  Bugs can be fixed, but lack of functionality needed for a debugger to be useful will cripple the IDE and render it an editor and code compiler, not a debugger.  I was frustrated by lack of local variable display window I ended up using gdb directly.  Although it is not better but at lease I can go very low level and get the work done.

If I remember correctly the  crashes came from gdb, if it tries to access not initialized variables.
If this in not fixed in gdb sources, there is no way for the IDE to fix this or even work around it easily.

[killerbot]

If I remember correctly the  crashes came from gdb, if it tries to access not initialized variables.
If this in not fixed in gdb sources, there is no way for the IDE to fix this or even work around it easily.

If this really is the case, then we should bring the feature back. People might say, hey CB crashes, while it was actually GDB, but then that same remark goes for eg Eclipse and other IDE's.

Next to that, from a programmers view, not initializing your variables, all hell should go loose upon you ;-)

As said, if that is the cause, the good programmers should not be punished.


I will try the patch when updated too, do we have an example code on how to reproduce such crash, will ask a colleague who uses eclipse to reproduce the crash too.

[oBFusCATed]

If this really is the case, then we should bring the feature back. People might say, hey CB crashes, while it was actually GDB, but then that same remark goes for eg Eclipse and other IDE's.

This is not the case.

Next to that, from a programmers view, not initializing your variables, all hell should go loose upon you ;-)

std::vector is always initialized, but after the constructor is called. If you inspect it before the constructor it is not.

Next to that, from a programmers view, not initializing your variables, all hell should go
I will try the patch when updated too, do we have an example code on how to reproduce such crash, will ask a colleague who uses eclipse to reproduce the crash too.

Won't happen in Eclipse, they use GDB/mi and probably aren't evaluating all elements, but have limits.

[ollydbg]

The bug report and my patch is posted here: GDB crash under Windows, I don't have GDB crash now.  , but GDB devs seems are not interested to fix bugs under Windows.

[killerbot]

it only occurs on windows ? or also on linux ?

[oBFusCATed]

it only occurs on windows ? or also on linux ?

Everywhere...

[ollydbg]

it only occurs on windows ? or also on linux ?

On Windows, when pass a long value (this is a random value) to malloc function, it will failed, then GDB crashes, what my patch do is to limit the size passed to malloc function.

Code

+	  if (length > local_opts.print_max)
+	    length = local_opts.print_max;

The value "ocal_opts.print_max = 200 " if you set on GDB command line: set print elements 200
I'm not sure how it works under Linux.

[MortenMacFly]

So please stay tuned... I'll post here.

Here it is, hopefully complete... sorry for the delay.

[cbrmm]

MortenMacFly

Thanks so much. When trying to apply your patch, however, it doesn't work.
Looking closer it seems that you patch against rev. 7239 but the only 12.11 currently available is rev. 7291.

Detail: I'm on Mint 15 and an example of patchs complaints is a file "src/CodeBlocks_wx29-unix.cbp" that doesn't exist.

I'd very much appreciate if you could provide a working patch because using D (rather than C++) I can't see much other than ints and bools.

Having a way to at least see all locals would be of great help.

[oBFusCATed]

I'd very much appreciate if you could provide a working patch because using D (rather than C++) I can't see much other than ints and bools.

Can you explain what is the problem here? Post a debug log from the debugger?
If GDB can print D structs/classes then it should work out of the box.

p.s. I doubt this patch will help with solving you problem, because by looking at it I think it works for simple values and not for structs/classes/arrays/etc.

[cbrmm]

Sorry for expressing myself clumsily.

I'm using Code:Block for D development and there seem to be serious problems to watch variables. So my compromise was to at least see local vars. This, however, doesn't work in 12.11 anymore.

With 10.05 it does work (local vars display) but I'd like, of course, the new CB version and additionally it's a PITA to install CB 10.05 package by package (on Linux Mint).

Ideas? Advice?

Thanks - R

[oBFusCATed]

You failed to say what is the exact problem again.
I don't intend to install a D compiler to check how it works with C::B.
So you'll has to provide a debug log from the debugger or continue to use 10.05... See the debugger setting for an option to enable it.

[cbrmm]

You failed to say what is the exact problem again.
I don't intend to install a D compiler to check how it works with C::B.
So you'll has to provide a debug log from the debugger or continue to use 10.05... See the debugger setting for an option to enable it.

Thanks so much but I don't intend to become a gdb expert. After all, I'm using an ide to *not* have to take care of stuff like that.

To my question: Simple issue.
In CB 10.05, when I enable "watches" in the debugger windows menu, I see local vars (and parameters) in the watches windows.
In CB 12.01 that doesn't work anymore.

Concerning D:

I'm perfectly O.K. with you possibly not caring about D related problems. But then CB shouldn't announce to support D.
I also understand that D is still a floating target and brings its own set of problems for CB, and that we users should - to the best of our abilities - try to do our part to get it working. I'm certainly willing to do that. But it would be helpful if you, the CB specialist, asked in a more CB newbie oriented manner for the detail info you need.
I'm perfectly willing to do my part, I am however not interested if I must first become a CB expert.

Side note: I'm new to D too and just making my first steps there. So, kindly don't expect too much know how from me.

Thanks - R

[oBFusCATed]

Thanks so much but I don't intend to become a gdb expert. After all, I'm using an ide to *not* have to take care of stuff like that.

I've stopped reading at this sentence, sorry, but you don't want help, just want to use 10.05 forever. If you want any help post a log from the debugger...

[oBFusCATed]

All local variable fanatics could checkout r9283 and start complaining that they are slow and cause gdb/c::b crashes.

Enjoy.

[ollydbg]

All local variable fanatics could checkout r9283 and start complaining that they are slow and cause gdb/c::b crashes.

Enjoy.

Hi, Obf, good work, I'm enjoying this new feature now.

[ollydbg]

@OBF:

With the latest GDB (git head), I think debugging/stepping under C::B with local variables shown is accelerated, see the latest comments in the below bug reports:

https://sourceware.org/bugzilla/show_bug.cgi?id=16196
https://sourceware.org/bugzilla/show_bug.cgi?id=12127

The main fix is that GDB now only fetch the maximize size of memory(defined by the user) from the inferior(debugee), GDB was fetch a vary large size(random value if it is an un-initilized local variable) of the memory from the inferior. The size of the element can be set such as:

Code

set print elements 200

So, if you have time, you can build GDB with the latest GIT head, and try to see whether it steps faster. (I heard before that GDB steps very slow if local variable is shown under C::B)

[oBFusCATed]

Won't help much. The problem is in codeblocks, not in GDB (most of the times).