eiskaltdcpp
macOS: The app crashes on launch if linked to libunwind
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)
It is really strange behavior of your build system, because eiskaltdcpp nowhere use libunwind directly:
$ grep -ri unwind * | wc -l
0
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.
It is highly likely that libunwind is a direct dependency of another dynamic library with which EskaltDC++ is linked.
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?
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.
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.