Application contains a native library file that is properly ELF aligned to 16 KiB, but it still crashes upon launch on an Android 16 KiB ARM64 system image

[Horácio Filho]

Hello,

I have built an Android application using a custom Android toolchain (the Delphi compiler for the Android 64-bit platform). I can confirm that the generated Android application contains a native library file that is properly ELF aligned to 16 KiB, but the application still crashes upon launch on an Android 16 KiB ARM64 system image.

The generated Android application is based on a single instance of the NativeActivity class. That instance serves as the surface for the FireMonkey framework to present the actual content of the application. That FireMonkey application behaves as expected on 4 KiB system images.    

Here is the confirmation that the native library is properly ELF aligned:

Here is the native crash dump:

The top most part of the backtrace can be symbolicated to something similar to:

Do you have any suggestions on what is causing the application crash?

Obrigado.

[Rich Schmitt]

Try adding the following to your NDK build:  "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"

I had issues with a NDK build with 16 kb pages.  This solved it.

[Dan Albert]

+Steven Moreland 

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/d2154523-18bd-492d-9c5e-1ba40bbccd8en%40googlegroups.com.

[Steven Moreland]

Hey, this appears to be a SEGV_ACCERR, so the page with the address is not loaded at all.

Here are the aspects of pthread_key_create to consider here:
1. parameter, 'pthread_key_t* key' may be at the wrong address.
2. parameter, key_destructor. Since this pointer is not read in this function, it's likely not the cause of the issue here.
3. global variable key_map is read. Since this is used in an application, it will be initialized much earlier, and much Android code calls this function, so since it fails here (and not in other calls to this function), I don't think there would be an issue here. Though, in the case of memory corruption, it is possible.
4. there could be a logic error in pthread_key_create which computes the bad address. However, since the function is used frequently, including on 16 KB devices, I don't think we have to worry about this case.

Here's what I'd suggest:
- For (1) more, could you print the address of the function?
- Can you share the text of the stack trace (or ideally symbolized with line numbers) so we can see where in this function it's crashing? (e.g. if it's crashing on "*key = i | KEY_VALID_FLAG;", the issue is assuredly at (1) and we need to investigate the client code)
- We also might want to run with HWASAN to discount some of these other cases.
- If you are not familiar with AllocTlsIndex, or the issue is specific to Delphi, we may want to open a chat directly with them.
- If you have a minimal repro, can you share it?