XCode Debugger: Code window does not match stack window

Question

Hi,

I'm trying to port a fairly large windows project based on SDL and WxWidgets to MacOs X.

For the first time ever on a Mac, I can run my application, but the debugger does not seem to work properly. When breaking into my application, the stack view seems to make sense, but when I click on one of the function names shown in the debugger stack view, the code view below shows me a completely different piece of code.

For example, I click on "main" in the stack view, but the code window below jumps to line 100 of stdexcept from the MacOS SDK.

I've tried using the debugger with a "hello world" project and everything worked, so the problem must be related to my project. I've already checked the following settings in the project options:

Generate Debug Symbols: 1 Level of Debug Symbols: All Symbols Optimization Level: None Build Variants: debug

I've also made sure that "Load Symbols Lazily" is switched off in the debugger preferences.

What could cause the debugger to malfunction?

Thanks,

Adrian

Edit: I have already ruled out Windows file endings by converting all .cpp and .h files to Unix line endings as suggested by sqook.

Second Edit: Since the problem only occurs in this particular project, I am posting here all settings that I have changed from the default settings (except the header search paths). Perhaps one of these could be the culprit?

ARCHS = $(NATIVE_ARCH) SDKROOT = macosx10.5 VALID_ARCHS = i386 x86_64 BUILD_VARIANTS = normal MACOSX_DEPLOYMENT_TARGET = 10.4 COPY_PHASE_STRIP = NO DEAD_CODE_STRIPPING = NO OTHER_LDFLAGS = $(OTHER_LDFLAGS_LIBBOOST) $(OTHER_LDFLAGS_QUOTED_FOR_PROJECT_1) $(OTHER_LDFLAGS_QUOTED_FOR_PROJECT_2) $(OTHER_LDFLAGS_WXWIDGETS) PREBINDING = NO PRODUCT_NAME = Gemsweeper FRAMEWORK_SEARCH_PATHS = $(HOME)/Library/Frameworks /Library/Frameworks $(FRAMEWORK_SEARCH_PATHS) HEADER_SEARCH_PATHS = $(HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_7) $(HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_6) /usr/local/include $(HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_1) $(HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_2) $(HOME)/Library/Frameworks/SDL.framework/Headers /Library/Frameworks/SDL.framework/Headers $(HEADER_SEARCH_PATHS) /opt/local/var/macports/software/boost/1.37.0_0+darwin_9/opt/local/include $(HOME)/Library/Frameworks/SDL.framework/Headers /Library/Frameworks/SDL.framework/Headers $(HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_3) $(HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_4) $(HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_5) LIBRARY_SEARCH_PATHS = /usr/local/lib /opt/local/lib GCC_DEBUGGING_SYMBOLS = full GCC_OPTIMIZATION_LEVEL = 0 OTHER_CFLAGS = $(WX_CXX_FLAGS) OTHER_CPLUSPLUSFLAGS = -I/usr/local/lib/wx/include/mac-ansi-debug-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ GCC_PREPROCESSOR_DEFINITIONS = NO_BASS_SOUND _DEBUG XCODE WXMAC GCC_WARN_ABOUT_RETURN_TYPE = YES GCC_TREAT_NONCONFORMANT_CODE_ERRORS_AS_WARNINGS = YES GCC_WARN_UNUSED_VARIABLE = YES HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_1 = '/Users/adriangrigore/Documents/Gemsweeper Mac' HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_2 = "/Users/adriangrigore/Documents/Gemsweeper Mac/Finity Engine VS 2003/WxNonogram" HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_3 = "/Users/adriangrigore/Documents/Gemsweeper Mac/Finity Engine VS 2003/Finity Engine VS 2003/myunits/resmanager" HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_4 = "/Users/adriangrigore/Documents/Gemsweeper Mac/Finity Engine VS 2003/Finity Engine VS 2003/myunits" HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_5 = "/Users/adriangrigore/Documents/Gemsweeper Mac/Finity Engine VS 2003/Finity Engine VS 2003" HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_6 = "/Users/adriangrigore/Documents/Gemsweeper Mac/Finity Engine VS 2003/Finity Engine VS 2003/myunits/compiler-dependent" HEADER_SEARCH_PATHS_QUOTED_FOR_PROJECT_7 = '/Users/adriangrigore/Documents/Gemsweeper Mac/3rd party/AntiGrain/include' OTHER_LDFLAGS_LIBBOOST = /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 OTHER_LDFLAGS_QUOTED_FOR_PROJECT_1 = '/Users/adriangrigore/Documents/Gemsweeper Mac/3rd party/FreeImage/Dist/libfreeimage.a' OTHER_LDFLAGS_QUOTED_FOR_PROJECT_2 = '/Users/adriangrigore/Documents/Gemsweeper Mac/3rd party/cpuinfo-1.0/libcpuinfo.a' OTHER_LDFLAGS_WXWIDGETS = -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

Hopefully last edit: I've just found out that the problem is in fact not tied to the XCode Debugger, but has to do with the underlying gdb. I am seeing exactly the same problem when debugging my program via the command line. I have therefore moved this question here.

Answer 1

Xcode is buggy. Very, very buggy. Even 3.x I had the same problem last evening when it would show looping over more than it should. Inserting some printf() showed it was the debugger IDE that was at fault.

However, you could try a clean build. And make sure you are using a debug build. And that all modules have been loaded.

Answer 2

I've noticed this too, and reported a bug to Apple about this. They denied the behavior, but suggested it could be caused by the wrong line endings in the file. Anyways, try converting the line endings to the unix/mac format, doing a full clean, and then running it.

Edit: I should have specified that in Xcode, there is a preference where you can save the line ending type. You can resave all the files there with the line ending of your choosing. However, this is also somewhat inconsistent (grr), so I'd recommend using flip, and doing something like:

find /wherever -name "*.cpp" -print -exec flip -u {} \;

Again, I can't guarantee that this will solve the problem, as I took Apple's advice and still ended up seeing the debugger stop a few dozen lines below my breakpoint.

Answer 3

See my SO answer here. SDL redefines main to SDL_main