Re: Crash in ___lldb_unnamed_symbol / cannot locate symbol "__start___objc_selectors" on Android

[Frederik Seiffert]

A quick semi-related update on this in case this useful to someone: in order to get Android Studio to locate debug information and resolve the "___lldb_unnamed_symbol" entries I needed to add "-Wl,--build-id=sha1" to the LDFAGS. This is now fixed in our Android toolchain.

Frederik

Am 01.07.2019 um 14:14 schrieb Frederik Seiffert <frederik@algoriddim.com>:

Hi,

I’ve been working on using a more up-to-date Clang with the Android toolchain (in order to use the 2.0 Objective-C runtime), and managed to integrate the Clang r353983 prebuilt into NDK r20.

While this seems to work well so far when targeting armeabi-v7a, I am getting the following errors when targeting arm64.

1. When using Qt to build a simple test app with Objective C, I’m getting the following runtime error when launching the app:

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__start___objc_selectors" referenced by "/data/app/org.qtproject.example.Qt_test-izIXM5mKlm3teJ8swIY-gQ==/lib/arm64/libQt-test.so"...

libQt-test here is the native library containing some basic C++ and Objective C code. This is linked against libobjc and libgnustep-base. What could be a reason for this symbol to be missing?

2. When using Android Studio to run the hello-objectivec sample app with the new Clang/NDK, I am getting a segmentation fault (SEGV_ACCERR) with the following backtrace. This seems to be triggered by any first time Objective C code is run.

art_sigsegv_fault 0x0000007ad1109c70

art::FaultManager::HandleFault(int, siginfo*, void*) 0x0000007ad110a1a8

___lldb_unnamed_symbol181$$app_process64 0x00000057bdeef13c

<unknown> 0x0000007b580086a0

snprintf 0x0000007b56dc3208

snprintf 0x0000007b56dc3208

___lldb_unnamed_symbol3539$$libgnustep-base.so 0x0000007ab649ae20

___lldb_unnamed_symbol3541$$libgnustep-base.so 0x0000007ab649b164

___lldb_unnamed_symbol6841$$libgnustep-base.so 0x0000007ab6638a84

objc_msg_lookup_internal 0x0000007ab5f24294

objc_msg_lookup_sender 0x0000007ab5f24038

___lldb_unnamed_symbol2600$$libgnustep-base.so 0x0000007ab642bf28

___lldb_unnamed_symbol2599$$libgnustep-base.so 0x0000007ab642be84

___lldb_unnamed_symbol4132$$libgnustep-base.so 0x0000007ab64bf0a4

... (about 24000 similar entries)

___lldb_unnamed_symbol1567$$libgnustep-base.so 0x0000007ab6390d38

___lldb_unnamed_symbol1577$$libgnustep-base.so 0x0000007ab63912c0

___lldb_unnamed_symbol5202$$libgnustep-base.so 0x0000007ab65602e8

objc_send_initialize 0x0000007ab5f16604

objc_msg_lookup_internal 0x0000007ab5f24114

objc_msg_lookup_sender 0x0000007ab5f24038

___lldb_unnamed_symbol4106$$libgnustep-base.so 0x0000007ab64bdf70

objc_send_initialize 0x0000007ab5f16604

objc_send_initialize 0x0000007ab5f162a4

objc_msg_lookup_internal 0x0000007ab5f24114

objc_msg_lookup_sender 0x0000007ab5f24038

Java_com_example_helloobjectivec_MainActivity_initializeGNUstep GSInitialize.m:32

As I cannot really make sense of either of these I would appreciate anyone’s thoughts on them.

Frederik