C++ exceptions can't be caught on x86 API 16 emulator when building for API 16

[tiwoc]

Description

When building for android-16 and running on an API 16 x86 emulator, exceptions can't be caught. When building the same project for android-15, execution on the API 16 emulator works as expected. Also, executables built for android-16 ARMv7 or v8 work as expected when run on API 16 emulators.

This can be reproduced with both NDK r15c and r16 beta 1 (the latter only with a patched toolchain file, see #504) and with both gcc and clang.

On host:

$ cmake .. -DCMAKE_TOOLCHAIN_FILE=/path/to/ndk-r16-beta1/build/cmake/android.toolchain.cmake -DANDROID_ABI=x86 -DANDROID_PLATFORM=android-16 -DANDROID_TOOLCHAIN=clang -DANDROID_STL=c++_shared -DANDROID_CPP_FEATURES="exceptions"

On emulator (after pushing libc++_shared.so and libgnustl_shared.so to tmp and exporting LD_LIBRARY_PATH=.):

root@android:/data/local/tmp # ./android-test
terminating with uncaught exception of type int
assertion "terminating with uncaught exception of type int" failed: file "/usr/local/google/buildbot/src/android/ndk-release-r16/external/libcxx/../../external/libcxxabi/src/abort_message.cpp", line 73, function "abort_message"
Segmentation fault 
139|root@android:/data/local/tmp #

When running an executable built with -DANDROID_STL=gnustl_shared, we get the following result:

root@android:/data/local/tmp # ./android-test
terminate called after throwing an instance of 'int'
terminate called recursively
Segmentation fault 
139|root@android:/data/local/tmp #

With -DANDROID_STL=c++_static or -DANDROID_STL=gnustl_static:

root@android:/data/local/tmp # ./android-test                              
Segmentation fault 
139|root@android:/data/local/tmp #

Workaround

Build for android-15 instead of android-16. When run on the same simulator as above, it works:

root@android:/data/local/tmp # ./android-test                              
1|root@android:/data/local/tmp #

Environment Details

• NDK Version: 16.0.4293906-beta1
• Build sytem: CMake
• Host OS: Fedora 26 x86_64
• Compiler: clang, gcc
• ABI: x86
• STL: c++_static, c++_shared, gnustl_static, gnustl_shared
• NDK API level: 16
• Device API level: 16

[ghost]

I encountered the same issue for ABI x86-64 on Windows.
API Level : 21 and 23
The issue occurs during an exception inside libPocoFoundation.so
The call stack is here : https://pastebin.com/fBeU1La0

This issue occurs only when building with Android Studio via CMake and Gradle:
We successfully build the libraries with CMake, NDK 15 and the Standalone Toolchain API-21 and used Qt to deploy the application.

[DanAlbert]

So it's not android-16 specifically that's the problem, it's PIE. For CMake, you should be able to unblock yourself with -DANDROID_PIE=OFF. Unfortunately it looks like ndk-build will turn on PIE even if APP_PIE is false when you're building for android-16 or higher.

[DanAlbert]

It's also worth noting that PIE only affects executables, so this shouldn't be a problem for your app unless you're shelling out to a binary you ship with your app (uncommon, but not unheard of). Still a problem because this is really harmful to unit testing, so will keep digging.

[DanAlbert]

Doesn't work on android-16 or android-17 emulators, but does work on android-18.

[DanAlbert]

According to the stack trace, abort is being called from a mov in _Unwind_RaiseException. Clearly a bad unwind.

[DanAlbert]

Possibly https://android-review.googlesource.com/c/platform/bionic/+/42821?

[rprichard]

libgcc calls dl_iterate_phdr, which reports an incorrect load-base / load-bias for a PIE executable on 16 and 17. For a non-PIE executable, it reports 0 (correct), but it also reports 0 for a PIE executable.

I think @DanAlbert's CL is the fix for dl_iterate_phdr.

AFAICT, it's easy to work around in libgcc. When a module's load-base is 0, libgcc can recalculate it by searching for the PT_PHDR segment in the program headers, which dl_iterate_phdr passes to the callback. I'll upload a libgcc patch.

I have a tool that dumps the Bionic module lists and shows the problem with dl_iterate_phdr:

PIE binary (android-16):

Executable base: 0xb77f7000
_r_debug module list (accessed via DT_DEBUG tag):
  l_addr=0x0 l_ld=0x0 l_name=(0xbfaceda3 "./a.out")
  l_addr=0x0 l_ld=0x0 l_name=(0xb77eb3e0 "/system/bin/linker")
  l_addr=0xb7728000 l_ld=0xb77b1e74 l_name=(0xb77eb63c "libc.so")
dl_iterate_phdr module list:
  size=16: dlpi_addr=0x0 dlpi_name=(0x0 "(null)") dlpi_phdr=0x0 dlpi_phnum=0
  size=16: dlpi_addr=0x0 dlpi_name=(0xbfaceda3 "./a.out") dlpi_phdr=0xb77f7034 dlpi_phnum=9
  size=16: dlpi_addr=0xb7728000 dlpi_name=(0xb77eb63c "libc.so") dlpi_phdr=0xb7728034 dlpi_phnum=6

PIE binary (android-17):

Executable base: 0xb77f9000
_r_debug module list (accessed via DT_DEBUG tag):
  l_addr=0x0 l_ld=0x0 l_name=(0xbfd05d2c "./a.out")
  l_addr=0xb77d5000 l_ld=0xb77edf04 l_name=(0xb77f7760 "/system/bin/linker")
  l_addr=0xb772c000 l_ld=0xb77c4e74 l_name=(0xb77ee6dc "libc.so")
dl_iterate_phdr module list:
  size=16: dlpi_addr=0x0 dlpi_name=(0x0 "(null)") dlpi_phdr=0x0 dlpi_phnum=0
  size=16: dlpi_addr=0x0 dlpi_name=(0xbfd05d2c "./a.out") dlpi_phdr=0xb77f9034 dlpi_phnum=9
  size=16: dlpi_addr=0xb772c000 dlpi_name=(0xb77ee6dc "libc.so") dlpi_phdr=0xb772c034 dlpi_phnum=7

PIE binary (android-18):

Executable base: 0xb77ec000
_r_debug module list (accessed via DT_DEBUG tag):
  l_addr=0xb77ec000 l_ld=0x0 l_name=(0xbfc6cd07 "./a.out")
  l_addr=0xb77cc000 l_ld=0xb77e9f04 l_name=(0xb77eacc0 "/system/bin/linker")
  l_addr=0xb7723000 l_ld=0xb77b7e70 l_name=(0xb77ca120 "libc.so")
dl_iterate_phdr module list:
  size=16: dlpi_addr=0x0 dlpi_name=(0x0 "(null)") dlpi_phdr=0x0 dlpi_phnum=0
  size=16: dlpi_addr=0xb77ec000 dlpi_name=(0xbfc6cd07 "./a.out") dlpi_phdr=0xb77ec034 dlpi_phnum=9
  size=16: dlpi_addr=0xb7723000 dlpi_name=(0xb77ca120 "libc.so") dlpi_phdr=0xb7723034 dlpi_phnum=7

Between android-17 and android-18, dl_iterate_phdr starts reporting a non-zero dlpi_addr for a PIE binary.

[rprichard]

https://android-review.googlesource.com/c/toolchain/gcc/+/711193

[rprichard]

The fix should be in r18 beta1.