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

[Jordan Schidlowsky]

A.  Awesome.  Thanks kindly for posting this.  This helps.

-Jordan

> On Jul 29, 2019, at 5:19 AM, Frederik Seiffert  
> wrote:
> 
> 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 > >:
>> 
>> 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 0x007ad1109c70
>>> art::FaultManager::HandleFault(int, siginfo*, void*) 0x007ad110a1a8
>>> ___lldb_unnamed_symbol181$$app_process64 0x0057bdeef13c
>>>  0x007b580086a0
>>> snprintf 0x007b56dc3208
>>> snprintf 0x007b56dc3208
>>> ___lldb_unnamed_symbol3539$$libgnustep-base.so 0x007ab649ae20
>>> ___lldb_unnamed_symbol3541$$libgnustep-base.so 0x007ab649b164
>>> ___lldb_unnamed_symbol6841$$libgnustep-base.so 0x007ab6638a84
>>> objc_msg_lookup_internal 0x007ab5f24294
>>> objc_msg_lookup_sender 0x007ab5f24038
>>> ___lldb_unnamed_symbol2600$$libgnustep-base.so 0x007ab642bf28
>>> ___lldb_unnamed_symbol2599$$libgnustep-base.so 0x007ab642be84
>>> ___lldb_unnamed_symbol4132$$libgnustep-base.so 0x007ab64bf0a4
>>> ... (about 24000 similar entries)
>>> ___lldb_unnamed_symbol1567$$libgnustep-base.so 0x007ab6390d38
>>> ___lldb_unnamed_symbol1577$$libgnustep-base.so 0x007ab63912c0
>>> ___lldb_unnamed_symbol5202$$libgnustep-base.so 0x007ab65602e8
>>> objc_send_initialize 0x007ab5f16604
>>> objc_msg_lookup_internal 0x007ab5f24114
>>> objc_msg_lookup_sender 0x007ab5f24038
>>> ___lldb_unnamed_symbol4106$$libgnustep-base.so 0x007ab64bdf70
>>> objc_send_initialize 0x007ab5f16604
>>> objc_send_initialize 0x007ab5f162a4
>>> objc_msg_lookup_internal 0x007ab5f24114
>>> objc_msg_lookup_sender 0x007ab5f24038
>>> 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
>> 
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

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 :
> 
> 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 0x007ad1109c70
>> art::FaultManager::HandleFault(int, siginfo*, void*) 0x007ad110a1a8
>> ___lldb_unnamed_symbol181$$app_process64 0x0057bdeef13c
>>  0x007b580086a0
>> snprintf 0x007b56dc3208
>> snprintf 0x007b56dc3208
>> ___lldb_unnamed_symbol3539$$libgnustep-base.so 0x007ab649ae20
>> ___lldb_unnamed_symbol3541$$libgnustep-base.so 0x007ab649b164
>> ___lldb_unnamed_symbol6841$$libgnustep-base.so 0x007ab6638a84
>> objc_msg_lookup_internal 0x007ab5f24294
>> objc_msg_lookup_sender 0x007ab5f24038
>> ___lldb_unnamed_symbol2600$$libgnustep-base.so 0x007ab642bf28
>> ___lldb_unnamed_symbol2599$$libgnustep-base.so 0x007ab642be84
>> ___lldb_unnamed_symbol4132$$libgnustep-base.so 0x007ab64bf0a4
>> ... (about 24000 similar entries)
>> ___lldb_unnamed_symbol1567$$libgnustep-base.so 0x007ab6390d38
>> ___lldb_unnamed_symbol1577$$libgnustep-base.so 0x007ab63912c0
>> ___lldb_unnamed_symbol5202$$libgnustep-base.so 0x007ab65602e8
>> objc_send_initialize 0x007ab5f16604
>> objc_msg_lookup_internal 0x007ab5f24114
>> objc_msg_lookup_sender 0x007ab5f24038
>> ___lldb_unnamed_symbol4106$$libgnustep-base.so 0x007ab64bdf70
>> objc_send_initialize 0x007ab5f16604
>> objc_send_initialize 0x007ab5f162a4
>> objc_msg_lookup_internal 0x007ab5f24114
>> objc_msg_lookup_sender 0x007ab5f24038
>> 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
> 

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

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

[Frederik Seiffert]

Hi David,

> Looking at your backtrace, it appears that you're seeing the bug in BFD ld.  
> With the -r option, it resolved the __start and __stop symbols early, then 
> ended up with a .o file that caused everything declared in it to be dropped 
> during final linkage.  This results in anything in the GNUstep Base Additions 
> library being discarded.  Linking GNUstep Base (and -base Additions) with 
> either lld or gold should fix this problem.

Thanks for the pointer, that was it – adding -fuse-ld=gold to the linker flags 
the projects work fine now with the new NDK/Clang.

Interestingly using LLD gave me a different segmentation fault: somehow 
class->dtable was NULL in objc_msg_lookup_internal(), causing a NULL-pointer 
dereference in SparseArrayLookup(). Any idea what could be going on here? Note 
that LLD is only "available for testing" in the NDK

> #0  0x007ab56a2ec4 in SparseArrayLookup (sarray=0x0, index=3042308324) at 
> ../sarray2.h:77
> #1  0x007ab56a20d0 in objc_msg_lookup_internal (receiver=0x7ab9aff8a0, 
> selector=0x7ab5562378 <.objc_selector_new_\00116\0010:8>, version=0x0) at 
> ../sendmsg2.c:100
> #2  objc_msg_lookup_sender (receiver=0x7ab9aff8a0, selector=0x7ab5562378 
> <.objc_selector_new_\00116\0010:8>, sender=0x0) at ../sendmsg2.c:200
> #3  0x007ab55600f4 in testObjC () at ../Qt-test/ObjC.m:20


Thanks,
Frederik

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

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

[David Chisnall]

Hi,


On 01/07/2019 15:38, Frederik Seiffert wrote:

Thanks for the explanation David.

I believe there was a bug in clang where I didn't add an empty symbol 
for compilation units that didn't contain any selectors.  If you then 
linked a program or a library that didn't contain any selectors then 
you'd see this error at link time.  This should now be fixed, but you 
can work around it by making sure that at least one of the 
Objective-C[++] files that you link includes at least one use of a 
selector.


After skimming CGObjCGNU.cpp in Clang I had the exact same thought, but 
I had only added ObjC code/selectors, not ObjC++. After adding both the 
app links fine. (Btw. I don’t think CGObjCGNU.cpp 
 currently 
emits empty symbols for selectors if none are found, only for protocols 
and classes).


It does:

https://github.com/llvm-mirror/clang/blob/44f7b2cea9a2ae54023740cf1a8c067d6b0e090a/lib/CodeGen/CGObjCGNU.cpp#L1603

Though I'm not sure if that has always been working.

However, now the Qt app also fails with the same backtrace as the one in 
Android Studio (issue #2 from my original email), but Qt’s debugger is 
showing me more info and think I have an idea about what’s going on now.


I think for some reason objc_send_initialize() is being called on 
classes before Objective C categories have been loaded. This causes 
various unrecognized selector calls because many internal functions in 
GNUstep are implemented in categories (e.g. NSObject (GNUstepBase)). In 
my specific stack trace, +[NSException raise:format:arguments:] was 
calling +[NSString stringWithFormat:arguments:] (implemented in the 
GNUstepBase NSString category), causing another exception ad infinitum. 
Replacing that NSString call in NSException with a non-category version 
causes it to crash in various other initializers calling category methods.


The way in which things are loaded is defined here (for the v2 ABI, the 
v1 ABI loads things one compilation unit at a time):


https://github.com/gnustep/libobjc2/blob/d16faeded958f94033092631b6988fb15654f995/loader.c#L189

For any binary, the runtime will:

1. Load all selectors and register them.
2. Load all protocols and register / unique them.
3. Load all references to protocols and update them to point to the 
canonical definition of the protocol.

4. Load all classes and resolve them.
5. Load all categories and resolve them.
5. Send +load to any classes that support them.
7. Register any class aliases.

The only ways that you can end up with a +initialize method being called 
before a category is resolved are:


- If it's in an __attribute__((constructor)) function or a C++ global 
initialiser that's called before Objective-C runtime init (except on 
Windows, where these are guaranteed to happen in the right order).

- If the code calling it is in a different library to the category.

I know on Apple platforms one must pass -all_load or -force_load to the 
linker to use categories in static libraries, but this doesn’t seem to 
be recognized by my linker (and doesn’t seem to be necessary for other 
ABIs). Is there anything else that might be going on here?


Apple's implementation is very different and is deeply coupled with 
their linker and loader.


Looking at your backtrace, it appears that you're seeing the bug in BFD 
ld.  With the -r option, it resolved the __start and __stop symbols 
early, then ended up with a .o file that caused everything declared in 
it to be dropped during final linkage.  This results in anything in the 
GNUstep Base Additions library being discarded.  Linking GNUstep Base 
(and -base Additions) with either lld or gold should fix this problem.


David

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

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

[Frederik Seiffert]

Thanks for the explanation David.

> I believe there was a bug in clang where I didn't add an empty symbol for 
> compilation units that didn't contain any selectors.  If you then linked a 
> program or a library that didn't contain any selectors then you'd see this 
> error at link time.  This should now be fixed, but you can work around it by 
> making sure that at least one of the Objective-C[++] files that you link 
> includes at least one use of a selector.

After skimming CGObjCGNU.cpp in Clang I had the exact same thought, but I had 
only added ObjC code/selectors, not ObjC++. After adding both the app links 
fine. (Btw. I don’t think CGObjCGNU.cpp 

 currently emits empty symbols for selectors if none are found, only for 
protocols and classes).

However, now the Qt app also fails with the same backtrace as the one in 
Android Studio (issue #2 from my original email), but Qt’s debugger is showing 
me more info and think I have an idea about what’s going on now.

I think for some reason objc_send_initialize() is being called on classes 
before Objective C categories have been loaded. This causes various 
unrecognized selector calls because many internal functions in GNUstep are 
implemented in categories (e.g. NSObject (GNUstepBase)). In my specific stack 
trace, +[NSException raise:format:arguments:] was calling +[NSString 
stringWithFormat:arguments:] (implemented in the GNUstepBase NSString 
category), causing another exception ad infinitum. Replacing that NSString call 
in NSException with a non-category version causes it to crash in various other 
initializers calling category methods.

I know on Apple platforms one must pass -all_load or -force_load to the linker 
to use categories in static libraries, but this doesn’t seem to be recognized 
by my linker (and doesn’t seem to be necessary for other ABIs). Is there 
anything else that might be going on here?

Thanks,
Frederik

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

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

[David Chisnall]

On 01/07/2019 13:14, Frederik Seiffert wrote:
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?


With the v2 ABI, all selectors are emitted as a symbol with hidden 
visibility and a name that is a mangling of their name and type encoding 
in the __objc_selectors section.  The linker can then see all selectors 
and deduplicate them (this is a big part of the binary size saving - 
which is usually 10-20% - relative to the GCC ABI, which forced the 
linker to keep a copy of every selector for every compilation unit that 
referenced it.  It also removes one or two instructions from the path to 
load each selector).


GNU-like linkers (lld, BFD ld, gold) provide magic __start_{section} and 
__stop_{section} symbol definitions for the start and end of any section 
with a name that is a valid C identifier.  The module initialisation 
structure for the v2 ABI contains pointers to __start___objc_selectors 
and __stop___objc_selectors, which the linker will fill in with the 
start and end of the __objc_selectors section.  This is then used by the 
runtime to iterate over all of the selectors in a library.


I believe there was a bug in clang where I didn't add an empty symbol 
for compilation units that didn't contain any selectors.  If you then 
linked a program or a library that didn't contain any selectors then 
you'd see this error at link time.  This should now be fixed, but you 
can work around it by making sure that at least one of the 
Objective-C[++] files that you link includes at least one use of a selector.


David

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

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

[Frederik Seiffert]

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 0x007ad1109c70
> art::FaultManager::HandleFault(int, siginfo*, void*) 0x007ad110a1a8
> ___lldb_unnamed_symbol181$$app_process64 0x0057bdeef13c
>  0x007b580086a0
> snprintf 0x007b56dc3208
> snprintf 0x007b56dc3208
> ___lldb_unnamed_symbol3539$$libgnustep-base.so 0x007ab649ae20
> ___lldb_unnamed_symbol3541$$libgnustep-base.so 0x007ab649b164
> ___lldb_unnamed_symbol6841$$libgnustep-base.so 0x007ab6638a84
> objc_msg_lookup_internal 0x007ab5f24294
> objc_msg_lookup_sender 0x007ab5f24038
> ___lldb_unnamed_symbol2600$$libgnustep-base.so 0x007ab642bf28
> ___lldb_unnamed_symbol2599$$libgnustep-base.so 0x007ab642be84
> ___lldb_unnamed_symbol4132$$libgnustep-base.so 0x007ab64bf0a4
> ... (about 24000 similar entries)
> ___lldb_unnamed_symbol1567$$libgnustep-base.so 0x007ab6390d38
> ___lldb_unnamed_symbol1577$$libgnustep-base.so 0x007ab63912c0
> ___lldb_unnamed_symbol5202$$libgnustep-base.so 0x007ab65602e8
> objc_send_initialize 0x007ab5f16604
> objc_msg_lookup_internal 0x007ab5f24114
> objc_msg_lookup_sender 0x007ab5f24038
> ___lldb_unnamed_symbol4106$$libgnustep-base.so 0x007ab64bdf70
> objc_send_initialize 0x007ab5f16604
> objc_send_initialize 0x007ab5f162a4
> objc_msg_lookup_internal 0x007ab5f24114
> objc_msg_lookup_sender 0x007ab5f24038
> 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

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep