GCC debugger stack trace displays wrong file name and line number

Question

I am trying to port a fairly large C++ project to using g++ 4.0 on Mac OS X. My project compiles without errors, but I can\'t get GDB to work properly. When I look at the stack

Answer 1

I've tried compiling an XCode SDL project template and did not experience the same problem, so it must be due to something special in my project.

Correct. Your project settings are the thing that is different.

You will need to disable the debug optimizations in the Xcode project settings for the debug build. Xcode unfortunately makes GDB jump to weird lines (out of order) when you would expect it to move sequentially.

Go to your project settings. Set the following

1) Instruction Scheduling   = None
2) Optimization Level       = None [-O0]
3) ZERO_LINK                = None

Your problems should go after after doing this. Here is the project settings screen that you need to change the settings on:

Answer 2

From your flags the debug information should be in the object files.

Does your project settings build the executable in one location then move the final executable to another location when completed? If this is the case then gdb may not be finding the objectects files and thus not correctly retrieving the debug information from the object files.

Just a guess.

Answer 3

Your cpp files certainly have debug symbols in them (the -gdwarf-2 option).

Do you use a separate dSYM file for the debug symbols? Or are they inside the object files. I would first try to use DWARF in dSYM files and see if that helps (or vice versa)

The third party libraries appear to be release builds though (unless you renamed them yourself of course) e.g. I know for sure boost uses the -d monniker in the library names to denote debug libraries (e.g. libboost_filesystem-mt-d.a).

Now, this shouldn't really pose a problem, it should just mean you can't step into the calls made to third party libraries. (at least not make any sense of it when you do ;) But since you have problems, it might be worth a try to link with debug versions of those libraries...

Answer 4

Can it be that you are using SDL? SDL redefines main so your main will be named SDL_main and that the SDL parts might be heavy optimized so down there you'll have problem getting good gdb output.

...just a thought

Read this

Answer 5

I got those symptoms, when my gdb version didn't match my g++ version.

Try to get the newest gdb.

Answer 6

WxWidgets do also define their own main if you use their IMPLEMENT_APP() macro

From here

As in all programs there must be a "main" function. Under wxWidgets main is implemented using this macro, which creates an application instance and starts the program.

IMPLEMENT_APP(MyApp)