GCC debugger stack trace displays wrong file name and line number

Answer 1

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 2

Are you compiling with optimization on? I've found that O2 or higher messes with the symbols quite a bit, making gdb and core files pretty much useless.

Also, be sure you are compiling with the -g option.

Answer 3

For a test, you could check if addr2line gives you expected values. If so, this would indicate that there's nothing wrong with the elf generated by your compile/link parameters and casts all suspicion on GDB. If not, then suspicion is still on both the tools and the elf file.

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

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 6

I encountered this several years ago when transitioning from the Codewarrior compilers to Xcode. I believe the way to get around this is to put the flag "-fno-inline-functions" in Other C Flags (for Dev only).

This problem was more pronounced on the PowerPC architecture for us.

What about if you remove the "-fvisibility-inlines-hidden" and "-mfix-and-continue" flags?

I've never had the "fix and continue" feature work properly for me.

Answer 7

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)

Answer 8

See my answer here

I have now downloaded and compiled the FreeImage sources and yes, the file b44ExpLogTable.cpp is compiled into libfreeimage.a. The problem looks like the script gensrclist.sh just collects all .cpp files without skipping the one with a main in. That script generates a file named Makefile.srcs but one is already supplied. (running it on my Leopard failed, some problem with sh - it worked if I changed sh to bash)

Before you have changed anything this gives an a.out

c++ libfreeimage.a

The file Makefile.srcs has already been created so you should be able to remove the file b44ExpLogTable.cpp from it. Then do

make -f Makefile.osx clean
make -f Makefile.osx

When this is done the above c++ libfreeimage.a should give the following error

Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Answer 9

I have a new thing you can try.

Just before your own main you can write

#ifdef main
#  error main is defined
#endif

int main(int argc, char *argv[]) {

this should give an error if you have some header that redefines main.

If you define an own you might get an warning where a previous definition was made

#define main foo

int main(int argc, char *argv[]) {

You can also try to undef just before your main

#undef main

int main(int argc, char *argv[]) {