constructor breakpoint issue

[tiwag]

i've the following project and want to set a breakpoint in

plotsamplefrm.cpp:44

but it doesn't break

does anyone know how i can set a breakpoint so that it breaks in the constructor ?

[attachment deleted by admin]

[MortenMacFly]

Hehe... nice one. I could't find a usual way to do this but if you are interested in, here is a workaround:
- add a dummy method to your class, eg:

Code

void PlotSampleFrm::Dummy()
{
  int i = 0;
}

- add a method call just before the line 44 (or whereever you want to break inside the consructor)
- add a breakpoint inside the dummy method at the line that contains int i = 0;
- run the debugger -> it will break at that line
- go stepwise (Alt+F7, "next instruction") until you are inside the constructor again -> just at the line you actually would like to have the BP...

I know, this is pointless, but at least it alows you to break at that point... :lol:

[tiwag]

the good old

Code

{ asm("int $3"); }

works too to get into the debugger


but i can't understand why this happens  :roll:

any ideas ?

[tiwag]

Hehe... nice one. I could't find a usual way to do this but if you are interested in, here is a workaround:
- add a dummy method to your class, eg:
...

i've tested your Dummy() method too and it works !
(thanks for pointing out)

now i'm even more confused !!!
what makes the difference

[thomas]

works too to get into the debugger


but i can't understand why this happens

That's easy. It is because the debugger catches all exceptions.

Try and drag a file onto Code::Blocks under Windows XP while the debugger is running. The debugger will report a segfault immediately! However, there is no segfault at all, it is just that some particularly bright and intelligent person at MS deemed it a good idea to implement drag and drop by firing off exceptions all over the time. The same goes for file selector boxes.

[tiwag]

works too to get into the debugger


but i can't understand why this happens

That's easy. It is because the debugger catches all exceptions.

Dear Thomas ! :lol: :lol: :lol:
that the debugger catches my forced exception is clear (at least for me) :lol: :lol: :lol:

what i don't understand is, that the breakpoint works with the Dummy() method called from the constructor
but obviously no set breakpoint within the constructor. 

[Game_Ender]

Does CB have this problem on linux? I am running:

Code

GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:01:44 GMT 2006)
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5341)

And at least in Xcode I can break in constructors so it is possible.

[thomas]

Dear Thomas ! :lol: :lol: :lol:
that the debugger catches my forced exception is clear (at least for me) :lol: :lol: :lol:

what i don't understand is, that the breakpoint works with the Dummy() method called from the constructor

That's easy, too.

The compiler generates several versions of the constructor to be able to implement virtual base classes (this happens regardless of whether or not you use virtual functions).
Although the linker sees these different constructors mangled differently, they have the same "real" name (even though they are physically different object code).
Thus, setting a breakpoint is russian roulette. You may be lucky to hit just the right one (the one that's actually called), or you may not be.

If you call a dummy function from the constructor and you set the BP into the dummy, then no matter which constructor is called, you still hit the dummy in any case (as there is only one).

[Pecan]

Does CB have this problem on linux? I am running:

Code

GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:01:44 GMT 2006)
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5341)

And at least in Xcode I can break in constructors so it is possible.

Yes. Apple has heavily modified the compiler and the debugger.

I've gotten clipped a number of times trying methods on Linux and windows CB that worked on MAC but not on "normal" gcc/gdb. Then thinking... duh... I'm not on the Mac now.

[marfig]

If you call a dummy function from the constructor and you set the BP into the dummy, then no matter which constructor is called, you still hit the dummy in any case (as there is only one).

I still prefer to set the break at the object initialization and then send rbreak ClassName::ClassName to the debugger

Arguably, it's more work since this has to be done everytime I start a debug session. But the good thing is that any BP set inside the constructor will start working