views:

954

answers:

5

I'm new to debugging with Eclipse.

I try to debug my app to know where it segfaults.

The problem is that Eclipse breaks within the STL, which is very annoying.

For example: I created a breakpoint in my source file on line 134, which works fine but if I hit F6 for "Step Over", Eclipse/gdb breaks in basic_string constructor used in the next line with std::cout.

Any hints on this? Is there a configuration option for Eclipse or such?

+1  A: 

Perhaps that's where it segfaults?

Dave Van den Eynde
no it segfaults cause of an stack overflow caused by a endless loop - im just searching for the causing line ^^but to answer your question: the loop starts by sending SIGINT to my app but i get those STL breaks also during startup - seems like everytime i use std::cout
John Doe
A: 

I haven't used Eclipse but I'm sure there is a "stack backtrace" or "call stack" view that you can use to see the call chain that ended up in the STL code.

flodin
yes there is such a view
John Doe
So, that solves your problem. Right?
flodin
A: 

if the code is optimized then it might break in the stl. Try compiling using debug mode and it might help.

And another thing is it might be sigfaulting there itself. Try looking at the code which calls the stl functons. stack trace should help.
A: 

Given limited information, this is what comes to mind,

  1. Step into (F5) instead of stepping over (F6) to locate where this is happening.
  2. If this does not work, upgrade CDT to the latest version and try again.
  3. If this does not work either, try using gdb without Eclipse.
  4. Last option, throw in a bunch of cerr outputs. Note cerr (which is not buffered) not cout.

If none of this works post more details.

Nikhil
A: 

I had similar problem. It's about inline functions (which stl cuases).

You need to add some compiler flags to generate some extra debug information. If you are using gcc see -g* flags (-ggdb for gdb debugger compliance, it gives you the most decent support for that types of debuggers).

Also you might want to turn off optimization.

P.s. I wasn't clear enough: it's not Eclipse's fault, it's compiler/debugger fault.

inazaruk