macOS: The app crashes on launch if linked to libunwind

[barracuda156]

UPD. Looks like it crashes only if linked to libunwind. Unfortunately, it does link to it, as long as it finds libunwind in the path.

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               eiskaltdcpp [25755]
Path:                  /Applications/MacPorts/*/eiskaltdcpp.app/Contents/MacOS/eiskaltdcpp
Identifier:            com.github.eiskaltdcpp
Version:               2.4.2+devel (2.4.2+devel)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2024-02-25 16:31:25.6256 +0700
OS Version:            macOS 14.3.1 (23D60)
Report Version:        12
Anonymous UUID:        08288255-726E-11E3-9DE3-9407366F4C9A

Sleep/Wake UUID:       7E02B724-CD85-4743-BD94-93227D35F0E1

Time Awake Since Boot: 290000 seconds
Time Since Wake:       12766 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000001, 0x0000000197d2fa6c

Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process:   exc handler [25755]

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libunwind.dylib               	       0x197d2fa6c _Unwind_GetIP + 244
1   libc++abi.dylib               	       0x18b46fc7c __gxx_personality_v0 + 588
2   libunwind.1.dylib             	       0x104e09144 unwind_phase2 + 140
3   libunwind.1.dylib             	       0x104e091d0 _Unwind_Resume + 52
4   eiskaltdcpp                   	       0x1044706c0 dcpp::File::File(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, int, int) + 552
5   eiskaltdcpp                   	       0x1044da2dc dcpp::Util::loadBootConfig() + 196
6   eiskaltdcpp                   	       0x1044d95a0 dcpp::Util::initialize(std::__1::map<dcpp::Util::Paths, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::less<dcpp::Util::Paths>, std::__1::allocator<std::__1::pair<dcpp::Util::Paths const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>>) + 860
7   eiskaltdcpp                   	       0x10445d8e8 dcpp::startup(void (*)(void*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&), void*) + 56
8   eiskaltdcpp                   	       0x10420b2d8 main + 668
9   dyld                          	       0x18b1350e0 start + 2360

Thread 1:
0   libsystem_pthread.dylib       	       0x18b4b0e28 start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib       	       0x18b4b0e28 start_wqthread + 0

Thread 3:
0   libsystem_pthread.dylib       	       0x18b4b0e28 start_wqthread + 0

Thread 4:
0   libsystem_pthread.dylib       	       0x18b4b0e28 start_wqthread + 0


Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x000000016bbfb290   x1: 0x00000000fffffffe   x2: 0x434c4e47432b2b00   x3: 0x000060000095d000
    x4: 0x000000016bbfadf0   x5: 0x0000000000023ea0   x6: 0x6261745f74706563   x7: 0x0000000000000630
    x8: 0x000000016bbfaef8   x9: 0x0000000104e100c8  x10: 0x000000016bbfac98  x11: 0x0000000000000000
   x12: 0x00000001044706c0  x13: 0x0000000104470498  x14: 0x0000000054000003  x15: 0x000000000000006c
   x16: 0x40000001044706c0  x17: 0x00000001044706c0  x18: 0x0000000000000000  x19: 0x000000016bbfadf0
   x20: 0x00000001044706c0  x21: 0x0000000000000002  x22: 0x000000010452ba68  x23: 0x0000000000000001
   x24: 0x000000016bbfb8f0  x25: 0x000000018b1b462b  x26: 0x434c4e47432b2b00  x27: 0x0000000000000000
   x28: 0x0000000000000000   fp: 0x000000016bbfac30   lr: 0x0000000197d2fa4c
    sp: 0x000000016bbfac20   pc: 0x0000000197d2fa6c cpsr: 0x20001000
   far: 0x0000000000000000  esr: 0xf200c471 (Breakpoint) pointer authentication trap IB

What it is linked to:

otool -L /Applications/MacPorts/*/eiskaltdcpp.app/Contents/MacOS/eiskaltdcpp
/Applications/MacPorts/eiskaltdcpp/eiskaltdcpp.app/Contents/MacOS/eiskaltdcpp:
	/opt/local/libexec/qt5/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.15.0, current version 5.15.12)
	/opt/local/libexec/qt5/lib/QtXml.framework/Versions/5/QtXml (compatibility version 5.15.0, current version 5.15.12)
	/opt/local/libexec/qt5/lib/QtMultimedia.framework/Versions/5/QtMultimedia (compatibility version 5.15.0, current version 5.15.12)
	/opt/local/libexec/qt5/lib/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility version 5.15.0, current version 5.15.12)
	/opt/local/libexec/qt5/lib/QtSql.framework/Versions/5/QtSql (compatibility version 5.15.0, current version 5.15.12)
	/opt/local/libexec/qt5/lib/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.15.0, current version 5.15.12)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 24.0.0)
	/opt/local/libexec/qt5/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.15.0, current version 5.15.12)
	/opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.15.0, current version 5.15.12)
	/opt/local/lib/libminiupnpc.17.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
	/opt/local/lib/libidn2.0.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.3.1)
	/opt/local/libexec/openssl3/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/libexec/openssl3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.157.0)
	/opt/local/lib/libunwind.1.dylib (compatibility version 1.0.0, current version 5.0.1)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

[tehnick]

It is really strange behavior of your build system, because eiskaltdcpp nowhere use libunwind directly:

$ grep -ri unwind * | wc -l
0

[barracuda156]

It is really strange behavior of your build system, because eiskaltdcpp nowhere use libunwind directly:

$ grep -ri unwind * | wc -l
0

@tehnick This is a relatively common bug on macOS in fact, nothing specific to eiskaltdcpp. It is Apple toolchain which decides to link to libunwind.

The only practical consideration would be to add a note for users that it is advised not to have libunwind installed during the build or not present in lib search paths.
We cannot fix it.

[tehnick]

It is highly likely that libunwind is a direct dependency of another dynamic library with which EskaltDC++ is linked.

[tehnick]

This is a relatively common bug on macOS in fact, nothing specific to eiskaltdcpp. It is Apple toolchain which decides to link to libunwind.

Thanks for a confirmation. I have never faced with this bug using Homebrew before...

We cannot fix it.

Are you sure that there are no workarounds which we may use in our cmake scripts?

[barracuda156]

It is highly likely that libunwind is a direct dependency of another dynamic library with which EskaltDC++ is linked.

I think the issue is that macOS already has libunwind somewhere in sysroot, and when a user installs a standalone libunwind, a conflict may occur. (As for why would someone do that – there is software requiring it.)
I did not try to investigate the issue deeply, I just encountered this problem with several ports.

[barracuda156]

Thanks for a confirmation. I have never faced with this bug with Homebrew before...

Well, to reproduce the issue you would need to install libunwind into some default location so that it can be picked, and then build eiskaltdcpp from source. If doing this in Homebrew does not cause any issues, then it may be worth looking at how they handled it.

For the record, I can only confirm libunwind -related crashes on Sonoma / aarch64 / libc++, no idea about x86 or alternative toolchain configurations.
I do not think I had any issues on powerpc with this. It could be aarch64-specific or at least more prevalent there.

Are you sure that there are no workarounds which we may use in our cmake scripts?

I am not aware of fixes from this side. In MacPorts we can just declare a build-time conflict, so a user will have to deactivate libunwind before the build.
Perhaps it is possible, just no one took up the task of finding out how.