GCC Debugger Stack Trace Displays Incorrect File Name and Line Number

Question

I am trying to port a fairly large project in C ++ to g ++ 4.0 on Mac OS X. My project compiles without errors, but I cannot get GDB to work correctly. When I look at the stack by typing "bt" on the GDB command line, all file names and line numbers are displayed incorrectly.

For example, according to the GDB stack trace, my main() function should be in stdexcept from the Mac OS X SDK, which makes no sense.

What can cause GDB to fail? I already checked the instructions for #line and #file in my code and made sure that the code only has UNIX line endings. I also cleaned and rebuilt the project. I also tried debugging the Hello World project, and it did not have the same problem.

Could the problem be related to one of the third-party libraries that I am linking, and how are they compiled? Or is it completely different?

The following are two examples of gcc and ld calls made by Xcode . AFAIK all cpp files in my project are compiled and linked with the same parameters.

/Developer/usr/bin/gcc-4.0 -x C ++ -arch i386 -fmessage-length = 0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -fpermissive -Wreturn-type -Wunused-variable -DNO_BASS_SOUND -D_DEBUG -DXCODE -D__WXMAC__ -isysroot / Developer / SDK / MacOSX10.5.sdk -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min = 10.4 -gdwarf-2 -D_FILE_OFFSET_FIT_BIT_LIT_LIT -D__WXDEBUG__ -D__WXMAC__ -c "/ Users / adriangrigore / Documents / Gemsweeper Mac / TSDLGameBase.cpp" -o "/ Users / adriangrigore / Documents / Gemsweeper Mac / assemblies / Gemsweeper Mac.build/Debug/Gemsweeper Mac.build/Obss normal / i386 / TSDLGameBase.o "

/ Developer / usr / bin / g ++ - 4.0 -arch i386 -isysroot / Developer / SDKs / MacOSX10.5.sdk "-L / Users / adriangrigore / Documents / Gemsweeper Mac / assemblies / debugs" -L / Developer / SDKs / MacOSX10 .5.sdk / USR / local / Library -L / opt / local / lib "-F / Users / adriangrigore / Documents / Gemsweeper Mac / builds / debugging" -F / Users / adriangrigore / Library / Frameworks -F / Developer / SDKs / MacOSX10.5.sdk / Library / Frameworks-filelist "/ Users / adriangrigore / Documents / Gemsweeper Mac / assemblies / Gemsweeper Mac.build/Debug/Gemsweeper Mac.build/Objects-normal/i386/Gemsweeper Mac.LinkFileList" - mmacosx-version-min = 10.4 / opt / local / lib / libboost_program_options-mt.a / opt / local / lib / libboost _filesystem-mt.a / opt / local / lib / libboost _serialization-mt.a / opt / local / lib / libboost _system-mt.a / opt / local / lib / libboost _thread-mt.a "/ Users / adriangrigore / Documents / Gemsweeper Ma c / third batch /FreeImage/Dist/libfreeimage.a "" / Users / adriangrigore / Documents / Gemsweeper Mac / third batch / CPUInfo -1.0 / libcpuinfo.a "-L / usr / local / lib -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL -lwx_macd_richtext-2.8 -lwx_macd_aui-2.8 -lwx_macd_xrc-2.8 -lwx_macd_qa-2.8 -lwx_macd_html- 2.8 -lwx_macd_adv-2.8 -lwx_macd_core-2.8 -lwx_base_carbond_xml-2.8 -lwx_base_carbond_net -2.8 -lwx_base_carbond-2.8 -framework SDL -framework Cocoa -o "/ Users / adriangrigore / Documents / Gemsweeper Mac / assemblies / Debug / Gemsweeper Mac.app/Contents/MacOS/Gemsweeper Mac"

Please note that I already asked a similar question about the Xcode debugger here , but I am posting a message since I just found out that this is not really an Xcode error, but a problem with GCC / ld / GDB.

Edit: My project uses the following third-party libraries: SDL , Boost , wxWidgets . I'm not sure if this matters for this problem, but I just wanted to mention this just in case.

I tried compiling the Xcode SDL project template and did not experience the same problem, so this should be due to something special in my project.

Second Edit . As I just found out, I was mistaken when searching for files with the string "This is automatically generated." I just found dozens of files with one line, all of which belong to FreeImage , one of the third-party libraries that I use. So the problem seems to be related to FreeImage, but I'm still not sure how to do this.

Answer 1

I got these symptoms when my gdb version did not match my g ++ version.

Try to get a new gdb.

Answer 2

Your cpp files, of course, have debugging symbols in them (option -gdwarf-2 ).

Are you using a separate dSYM file for debugging characters? Or they are inside the object files. First I tried using DWARF in dSYM files and see if this helps (or vice versa)

Third-party libraries appear to be release builds (unless of course you rename them yourself), for example. I know for sure that boost uses -d monniker in library names to refer to debug libraries (e.g. libboost_filesystem-mt-da ).

Now this should not be a problem, it just means that you cannot go into calls to third-party libraries. (at least it makes no sense when you do this;) But since you have problems, it might be worth trying to link them to debug versions of these libraries ...

Answer 3

Are you planning on optimizing? I found that O2 or higher is a mess with characters quite a bit, which makes gdb and core files almost useless.

Also, make sure that you compile the -g option.

Answer 4

For the test, you can check if addr2line gives the expected values. If this is the case, it will mean that there is nothing wrong with the ELF generated by your compilation / link parameters and raises all suspicions about GDB. If not, then the suspicion still persists in both the tools and the ELF file.

Answer 5

Maybe you are using SDL? SDL overrides main , so your main will be called SDL_main and that parts of the SDL can be highly optimized, so there will be a problem with getting good gdb output.

... just a thought

Read it

Answer 6

I tried compiling the Xcode SDL project template and did not experience the same problem, so it should be related to something special in my project.

Correctly. Your project settings are two different things.

You will need to disable debugging optimization in the Xcode project settings to build debugging. Xcode, unfortunately, makes GDB jump onto strange lines (out of order) when you expect it to move sequentially.

Go to your project settings. Install the following

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

After that, your problems should go. Here is the project settings screen that needs to be changed to:

alt text http://i39.tinypic.com/sb6hb9.png

Answer 7

Of the flags, debugging information should be in object files.

Does your project settings set the executable in one place and then complete the final executable in another place? If this is the case, then gdb may not find object files and, therefore, incorrectly extract debugging information from object files.

Just to guess.

Answer 8

I came across this a few years ago when moving from Codewarrior compilers to Xcode. I believe that a way around this is to set the " -fno-inline-functions " flag to Other C Flags (Dev only).

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

What about removing the "-fvisibility-inlines-hidden" and "-mfix-and-continue" flags?

I never had a fix and continue function for me.

Answer 9

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

From here

As with all programs, a “core” function must exist. Under wxWidgets, main is implemented using this macro, which creates an instance of the application and runs the program.

IMPLEMENT_APP(MyApp)

Answer 10

See my answer here

Now I downloaded and compiled FreeImage sources and yes, the b44ExpLogTable.cpp file b44ExpLogTable.cpp compiled in libfreeimage.a . The problem is this: the gensrclist.sh script just collects all the .cpp files, not missing the one that has the main one. This script creates a file called Makefile.srcs , but one is already supplied. (running it on my Leopard failed, some problems with sh - it worked if I changed sh to bash )

Before changing anything, this gives a.out

 c++ libfreeimage.a 

The Makefile.srcs file has already been created, so you can delete the b44ExpLogTable.cpp file from it. Then do

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

If this is done, the above c++ libfreeimage.a should contain 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 11

I have a new thing that you can try.

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 a header that overrides main .

If you define your own, you may receive a warning in which the previous definition was made.

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

You can also try undef just before main

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