Breakpoint in constructor/destructor

[tom0769]

Hi,

I'm using winXP/2K.
I have a problem with setting breakpoints in constructors/destructors.
Sometimes the debugger stops at the desired point, sometimes not.
I could not find the reason for this.
If for example a breakpoint in a destructor does not work, I set
the breakpoint in a function called in the destructor and the debugger stops there.
I step through this function an then reach the destructor.

Do I have to consider special settings or is it a problem with gdb?
I used DEV-C++ before and there where similar problems.

Tom

[Profic]

I've read about this but can't remember where. Due to standart compiler generate not one constructor|destructor body, but many. That's why breakpoints in them didn't work as expected. However there was mentioned that gdb 6.3 can handle this situation in proper way.

[Urxae]

Are you compiling with optimizations on? If so, turn them off. Optimizations can do weird things when debugging, as things may be reordered or optimized out. Also, debugging information such as linenumbers may not always play nice with optimizations (especially inlining).
If you're debugging something that only shows up while optimizations are on, don't be surprised if debugging doesn't work as you expected.

My first guesses as to skipping breakpoints in this scenario would be

• the breakpoint is placed on a line that is optimized out. Does it do anything that is observable afterwards? If so the next question is: is it observed afterwards? The compiler is free to perform any optimization that doesn't change what the program does, so if the program runs with the exact same result without that line it is free to generate no code for it at all, and so there might be no place to break on.
• the destructor is inlined. I'm not sure if the debugging information includes the correct information about linenumbers that code generated for inlined functions comes from, it might show as the location of the call point.

[RayGun]

Hello, people!

Have recently started toying with Code::Blocks (1.0 rc 2), looks better then Dev-C++ to me.

However, I've got the same problem with constructors/destructors and GDB.
GDB is 6.3, optimizations are off, debugging symbols/profile code when executed - on.

Cannot hit breakpoints in constructor/destructor (although step-in reaches the constructor).

Any ideas on how to remedy this?

[mandrav]

Wait for the next update. It will set breakpoints in ctors/dtors.
(it should support it already but a bug prevented this)

[RayGun]

Yay! That'd be cool! 

Strangely, when I went to GDB site, I found this in their release notes (for 6.3) -

gdb/1091: Constructor breakpoints ignored
gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints

When gcc 3.x compiles a C++ constructor or C++ destructor, it generates
2 or 3 different versions of the object code.  These versions have
unique mangled names (they have to, in order for linking to work), but
they have identical source code names, which leads to a great deal of
confusion.  Specifically, if you set a breakpoint in a constructor or a
destructor, gdb will put a breakpoint in one of the versions, but your
program may execute the other version.  This makes it impossible to set
breakpoints reliably in constructors or destructors.

gcc 3.x generates these multiple object code functions in order to
implement virtual base classes.  gcc 2.x generated just one object code
function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
ABI for C++ which requires multiple object code functions.

But I prefer to think 'twas some kind of mistake and stick with Mandrav's words

[mandrav]

But I prefer to think 'twas some kind of mistake and stick with Mandrav's words

No, that's not a mistake. It's the actual explanation of the problem.
We *do* have a workaround though

[Bonanza]

Are there any news on this?

Maybe this can inspire someone (it actually works):
http://mailman.isi.edu/pipermail/ns-users/2005-November/052583.html

One other thing, I made C::B run my own "debugger initialization command" (source gdb.txt) setting some breakpoints:

Code

> source gdb.txt
Breakpoint 1 at 0x4013a9: file main.cpp, line 30.
Breakpoint 2 at 0x4013d2: file main.cpp, line 36.
Breakpoint 3 at 0x401411: file main.cpp, line 42.
Breakpoint 4 at 0x4014c4: file main.cpp, line 83.
Breakpoint 5 at 0x401518: file main.cpp, line 90.
(gdb)
> directory C:/cppcourse/Line_example2/
(gdb)
> delete breakpoints
(gdb)

However the breakpoints was automatically removed 

Any chance that breakpoints could be removed before running the C::B "debugger initalization commands"?

[sethjackson]

Try a nightly build from here, and use gdb 6.3.

http://forums.codeblocks.org/index.php?board=20.0

Quote from the G-man. I mean mandrav..... :lol:

Please people, don't resurrect one year old threads!

From here.

http://forums.codeblocks.org/index.php?topic=157.msg23669#msg23669

[Bonanza]

OK sorry, what do I do? Open a new thread and refer to this?

I tried with the 28 of april build, and if I am doing everything correct, the problem is not fixed.

I was just wondering if the workaround is already available(November 17, 2005)? :

We *do* have a workaround though

Thanks in advance, your all so cool:-)

[mandrav]

I was just wondering if the workaround is already available(November 17, 2005)?

Should be. Set the breakpoint on the constructor's first line, i.e:

Code: cpp

AClass::AClass(int x) // <-- put the breakpoint here
{
}

[Bonanza]

Thanks mandrav.

I tried that:-(

I am using gdb 6.3 and gcc 3.4.4. I updated to the nightly build previously mentioned (by overwritting files in the install folder).

I set the breakpoints like on the picture attached (it is breaking perfectly on a breakpoint in my main function).

The code example I used is also attached.

It works all fine if I enter the following "gdb user commands":

Code

b _ZN7Point2DC1Eii
b _ZN7Point2DC1Ev
b _ZN7Point2DC1ERKS_
b _ZN6Line2DC1E7Point2DS0_
b _ZN6Line2DD1Ev

I must be doing something else wrong I guess?!?

[attachment deleted by admin]

[mandrav]

Try sending this command to gdb:

Code

break Point2D::Point2D

[Bonanza]

OK

Then I get this from the debugger window:

Code

> break Point2D::Point2D
[0] cancel
[1] all
[2] Point2D::Point2D(Point2D const&) at main.cpp:42
[3] Point2D::Point2D() at main.cpp:36
[4] Point2D::Point2D(int, int) at main.cpp:30
> 

And the dubugger hangs:-(

Cannot enter "1" anywhere?

[mandrav]

My bad, try rbreak Point2D::Point2D