Debugging on the Xcode

However, trying to Run/Debug the application from inside Xcode fails - the application is crashing.

What does that crash look like?

One trick you can use here is to choose Debug > Detach. The debugger will then detach allow the app to crash in a way that generates a crash report. If you post that crash report here, I’m happy to take a look.

See Posting a Crash Report for advice on how to post crash reports.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@QuinnTheEskimo,

I just did the "Detach" thing and got the attached report.

If you could take a look - it would be great.

TIA!!

The immediate cause of your crash is ASan.

Application Specific Information:
=================================================================
==23123==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000002d8 (pc 0x000103ee8a10 bp 0x7ffeefbfa160 sp 0x7ffeefbfa140 T0)
==23123==The signal is caused by a READ memory access.
==23123==Hint: address points to the zero page.

Consider the crashing backtrace:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib                … __pthread_kill + 10
1   libsystem_pthread.dylib               … pthread_kill + 333
2   libsystem_c.dylib                     … abort + 127
3   libclang_rt.asan_osx_dynamic.dylib    … __sanitizer::Abort() + 70
4   libclang_rt.asan_osx_dynamic.dylib    … __sanitizer::Die() + 196
5   libclang_rt.asan_osx_dynamic.dylib    … __sanitizer::ReportFile::Write(char const*, unsigned long) + 116
6   libclang_rt.asan_osx_dynamic.dylib    … __sanitizer::SharedPrintfCode(bool, char const*, __va_list_tag*) + 590
7   libclang_rt.asan_osx_dynamic.dylib    … __sanitizer::Printf(char const*, ...) + 146
8   libclang_rt.asan_osx_dynamic.dylib    … __sanitizer::StackTrace::Print() const + 350
9   libclang_rt.asan_osx_dynamic.dylib    … __asan::ErrorDeadlySignal::Print() + 639
10  libclang_rt.asan_osx_dynamic.dylib    … __asan::ScopedInErrorReport::~ScopedInErrorReport() + 39
11  libclang_rt.asan_osx_dynamic.dylib    … __asan::ReportDeadlySignal(int, __sanitizer::SignalContext const&) + 162
12  libclang_rt.asan_osx_dynamic.dylib    … __asan::AsanOnDeadlySignal(int, void*, void*) + 157
13  libsystem_platform.dylib              … _sigtramp + 26
14  ???                                   … 0 + 0
15  libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxDisplayFactoryMacOSX::GetFromWindow(wxWindow const*) + 161 (display.cpp:238)

Frames 13 through 0 are ASan goo, and it’s likely that frame 15 is the cause. However, it’s possible that ASan is obscuring the real cause so I recommend that you (temporarily) disable ASan and reproduce the problem. I think that’ll cause Xcode to display an error that’s much closer to the actual cause [1].

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] ASan is a great tool in general but in this specific case, a dereference of NULL, the problem would have triggered a crash anyway and by disabling ASan you get closer to that crash.

@QuickTheEskimo,

I turned off ASAN and re-run the program.

Attached is the crash report. Please review.

I turned off ASAN

No you didn’t )-: That crash report is still showing ASan stuff:

==23123==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000002d8 (pc 0x000103ee8a10 bp 0x7ffeefbfa160 sp 0x7ffeefbfa140 T0)

ps If you can post the text of your crash report, rather than an RTF file, that’d make things easier.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@QuinnTheEskimo,

I hope now I turn everything off ;-)

See the crash report as a text file...

Thank you.

I hope now I turn everything off

You did indeed. Yay!

Looking at that crash report it pretty much tells us what ASan was telling us. Consider this:

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000000000002d8
Exception Note:        EXC_CORPSE_NOTIFY

The immediate cause of the crash was you accessing a bad pointer. The address, 0x02d8, suggests that it was a nil pointer to a large object, where the accessed member was at offset 0x02d8.

The crashing thread’s backtrace looks like this

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxNonOwnedWindow::GetWXWindow() const + 16 (nonownedwnd_osx.cpp:494)
1   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxDisplayFactoryMacOSX::GetFromWindow(wxWindow const*) + 161 (display.cpp:238)
2   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxDisplay::GetFromWindow(wxWindow const*) + 153 (dpycmn.cpp:116)
3   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxDisplay::wxDisplay(wxWindow const*) + 33 (dpycmn.cpp:92)
4   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxDisplay::wxDisplay(wxWindow const*) + 29 (dpycmn.cpp:96)
5   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxTopLevelWindowBase::DoCentre(int) + 168 (toplvcmn.cpp:251)
6   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxTopLevelWindowBase::CentreOnScreen(int) + 37 (toplevel.h:224)
7   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxWizard::DoWizardLayout() + 178 (wizard.cpp:715)
8   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxWizard::ShowPage(wxWizardPage*, bool) + 3147 (wizard.cpp:682)
9   libwx_osx_cocoau_core-3.2.0.0.0.dylib … wxWizard::RunWizard(wxWizardPage*) + 180 (wizard.cpp:729)
10  liblibdialogs.dylib                   … DatabaseProfile + 184 (dialogs.cpp:157)
11  liblibdbloader.dylib                  … ConnectToDb + 4329 (dbloader.cpp:150)
12  abc.dbhandler                         … MainFrame::Connect() + 1989 (mainframe.cpp:286)
13  abc.dbhandler                         … MainFrame::OnDatabase(wxCommandEvent&) + 99 (mainframe.cpp:388)
14  libwx_baseu-3.2.dylib                 … wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const + 134 (appbase.cpp:659)
15  libwx_baseu-3.2.dylib                 … wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const + 149 (appbase.cpp:670)
16  libwx_baseu-3.2.dylib                 … wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 220 (event.cpp:1432)
17  libwx_baseu-3.2.dylib                 … wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 236 (event.cpp:1039)
18  libwx_baseu-3.2.dylib                 … wxEvtHandler::TryHereOnly(wxEvent&) + 128 (event.cpp:1628)
19  libwx_baseu-3.2.dylib                 … wxEvtHandler::TryBeforeAndHere(wxEvent&) + 77 (event.h:4007)
20  libwx_baseu-3.2.dylib                 … wxEvtHandler::ProcessEventLocally(wxEvent&) + 47 (event.cpp:1561)
21  libwx_baseu-3.2.dylib                 … wxEvtHandler::ProcessEvent(wxEvent&) + 324 (event.cpp:1534)
22  libwx_osx_cocoau_core-3.2.dylib       … wxWindowBase::TryAfter(wxEvent&) + 168 (wincmn.cpp:3536)
23  libwx_baseu-3.2.dylib                 … wxEvtHandler::ProcessEvent(wxEvent&) + 378 (event.cpp:1547)
24  libwx_baseu-3.2.dylib                 … wxEvtHandler::SafelyProcessEvent(wxEvent&) + 47 (event.cpp:1650)
25  libwx_osx_cocoau_core-3.2.dylib       … wxWindowBase::HandleWindowEvent(wxEvent&) const + 37 (wincmn.cpp:1553)
26  libwx_osx_cocoau_core-3.2.dylib       … wxToolBarBase::OnLeftClick(int, bool) + 171 (tbarbase.cpp:725)
27  libwx_osx_cocoau_core-3.2.dylib       … wxToolBarTool::Action() + 218 (toolbar.mm:239)
28  libwx_osx_cocoau_core-3.2.dylib       … -[wxNSToolbarItem clickedAction:] + 74 (toolbar.mm:382)
29  com.apple.AppKit                      … -[NSToolbarButton sendAction:to:] + 75
…

Frame 29 is AppKit handling a toolbar button click. Frames 28 through 14 are your third-party UI framework. Frames 12 through 11 are your code, and then it’s back to your UI framework in frame 10. That contines down to frame 0 where you crash.

All of these frames seem to have reasonable symbols associated, so I recommend that you work through the logic in your program to see how you got to the point where you’re accessing members from a nil object.

ps Don’t forgot to turn ASan back on again when you’re done!

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@QuinnTheEskimo,

I understand that.

The problem is that running the application from Terminal is successful (as I wrote in the OP) - no crash like this occur.

Is there an explanation to that?

Thank you.

I have another question in regards to this.

From the Xcode Debug Console:

dyld: loaded: /Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug/dbhandler.app/Contents/MacOS/dbhandler
dyld: loaded: /Applications/Xcode.app/Contents/Developer/usr/lib/libBacktraceRecording.dylib
dyld: loaded: /Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib
dyld: loaded: /Applications/Xcode.app/Contents/SharedFrameworks/../Developer/Platforms/MacOSX.platform/Developer/Library/Debugger/libViewDebuggerSupport.dylib
dyld: loaded: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
dyld: loaded: /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
dyld: loaded: /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
dyld: loaded: /Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug/dbhandler.app/Contents/MacOS/../Frameworks/libwx_osx_cocoau_xrc-3.2.dylib
dyld: loaded: /Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug/dbhandler.app/Contents/MacOS/../Frameworks/libwx_osx_cocoau_html-3.2.dylib
dyld: loaded: /Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug/dbhandler.app/Contents/MacOS/../Frameworks/libwx_osx_cocoau_qa-3.2.dylib
dyld: loaded: /Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug/dbhandler.app/Contents/MacOS/../Frameworks/libwx_osx_cocoau_adv-3.2.dylib
dyld: loaded: /Users/igorkorot/wxWidgets/buildC11/lib/libwx_osx_cocoau_core-3.2.0.0.0.dylib
dyld: loaded: /Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu_xml-3.2.0.0.0.dylib
dyld: loaded: /Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu_net-3.2.0.0.0.dylib
dyld: loaded: /Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu-3.2.0.0.0.dylib
dyld: loaded: /Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug/liblibtabledataedit.dylib
dyld: loaded: /Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug/liblibdbwindow.dylib
dyld: loaded: /Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug/liblibdialogs.dylib

Is there a reason the libaries are loaded from the Bundle and from the place I build them?

Thank you.

Is there an explanation to that?

There are lots of potential explanations for that. When you run an app from Terminal it inherits an environment that’s very different from the one it gets from Xcode. And that, in turn, in somewhat different from the one it gets when you double click it in the Finder.

As to which one applies, it’s hard to say without more debugging.

Is there a reason the libaries are loaded from the Bundle and from the place I build them?

Probably because of the way you’re referencing the libraries. The dynamic linker has a complex algorithm for finding the libraries you import, partly because it’s a complex problem but also for historical reasons and to support edge cases (like debugging). However, when it comes to deployment there are only two strategies that work well:

• Install your library at an absolute path, use that absolute path as its install name, and import it using that absolute path.

• Use an rpath-relative path as the library’s install name and import it using that rpath-relative name. Then add an rpath entry in the loading program so that the dynamic linker can find it.

Given that you’re building an app, you have to use the second approach. I talk about this in depth in Embedding nonstandard code structures in a bundle.

As to what that’s causing the specific behaviour you’re seeing, it’s hard to say without pulling apart those libraries to see how their install names are set up.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@QuinnTheEskimo,

[quote] There are lots of potential explanations for that. When you run an app from Terminal it inherits an environment that’s very different from the one it gets from Xcode. And that, in turn, in somewhat different from the one it gets when you double click it in the Finder.

As to which one applies, it’s hard to say without more debugging. [/quote]

What do I need to do in terms of debugging? Only one library should be loaded and its from the Bundle.

From the post-install script:

#Copy and relink wxWidgets base library
echo “Copy wxWidgets base library”
cp -f ~/wxWidgets/buildC11/lib/libwx_baseu-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_baseu-3.2.dylib"

install_name_tool -id '@rpath/Frameworks/libwx_baseu-3.2.dylib' "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_baseu-3.2.dylib"

# Copy and relink network library
echo “Copy and relink wxWidgets network library”
cp -f ~/wxWidgets/buildC11/lib/libwx_baseu_net-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_baseu_net-3.2.dylib"

install_name_tool -id '@rpath/Frameworks/libwx_baseu_net-3.2.dylib' "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_baseu_net-3.2.dylib"

install_name_tool -change '/Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu-3.2.0.0.0.dylib' '@executable_path/../Frameworks/libwx_baseu-3.2.dylib' "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_baseu_net-3.2.dylib"

# Copy and relink XML library
echo “Copy and relink wxWidgets XML library”
cp -f ~/wxWidgets/buildC11/lib/libwx_baseu_xml-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_baseu_xml-3.2.dylib"

install_name_tool -id '@rpath/Frameworks/libwx_baseu_xml-3.2.dylib' "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_baseu_xml-3.2.dylib"

install_name_tool -change "/Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu-3.2.0.0.0.dylib" @executable_path/../Frameworks/libwx_baseu-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_baseu_xml-3.2.dylib"

# Copy the core library
echo "Copy core library"
cp -f ~/wxWidgets/buildC11/lib/libwx_osx_cocoau_core-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_osx_cocoau_core-3.2.dylib"

install_name_tool -id '@rpath/Frameworks/libwx_osx_cocoau_core-3.2.dylib' "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_osx_cocoau_core-3.2.dylib"

install_name_tool -change "/Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu-3.2.0.0.0.dylib" @executable_path/../Frameworks/libwx_baseu-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libwx_osx_cocoau_core-3.2.dylib"

# Relink the main binary
echo "Relinking the application"
install_name_tool -change "/Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu-3.2.0.0.0.dylib" @executable_path/../Frameworks/libwx_baseu-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/MacOS/dbhandler"

install_name_tool -change "/Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu_net-3.2.0.0.0.dylib" @executable_path/../Frameworks/libwx_baseu_net-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/MacOS/dbhandler"

install_name_tool -change "/Users/igorkorot/wxWidgets/buildC11/lib/libwx_baseu_xml-3.2.0.0.0.dylib" @executable_path/../Frameworks/libwx_baseu_xml-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/MacOS/dbhandler"

install_name_tool -change "/Users/igorkorot/wxWidgets/buildC11/lib/libwx_osx_cocoau_core-3.2.0.0.0.dylib" @executable_path/../Frameworks/libwx_osx_cocoau_core-3.2.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/MacOS/dbhandler"

This is what I am doing in terms of finalizing the build.

Do you see anything wrong with this?

Now, in the Xcode project I did add those libraries in the "Build Settings -> Other Linker Flag -> Debug" as follows:

-L/Users/igorkorot/wxWidgets/buildC11/lib -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL -lwx_osx_cocoau_xrc-3.2 -lwx_osx_cocoau_html-3.2 -lwx_osx_cocoau_qa-3.2 -lwx_osx_cocoau_adv-3.2 -lwx_osx_cocoau_core-3.2 -lwx_baseu_xml-3.2 -lwx_baseu_net-3.2 -lwx_baseu-3.2 -L/Users/igorkorot/dbhandler/dbhandler/Build/Products/Debug

So the linking happens from the place the libraries are built, but then post-install script changes it and relink the code appropriately.

This is from my external GUI library.

If you can help me resolve the library loading double, it would be great.

Thank you.

P.S.: If its too hard - I can give you a link to the GitHub repo to look at the Xcode project. Let me know.

I can give you a link to the GitHub repo to look at the Xcode project.

Unfortunately I don’t have that much time to spend on issues here on DevForums. I recommend that you open a DTS tech support incident and one of us — maybe me, maybe a colleague who handles tools issues — can look at your issue in that depth.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"