dynamic_cast form pointers is not working when linked with libc++_shared (ndk r15, r16b1)

[andreya108]

Description

Please help, I'm trying to figure out the reason, but still no luck. Maybe it is a bug.

Our project contains several .so which parts are building in different ways (for example, boost and other 3dp libs with standalone toolchains, main part which is bundled in aar with ndk-build and the app itself and jni part with gradle/cmake.

When I've switched to ndk16-b1 and libc++_shared all dynamic_cast's in c++ code from pointers to derived_class stored in std::list<base_class*> turned to nullptr.

For example:

class A {}
class B : A {}
std::list < A * > aList;
aList.add( new B() );
A* aPtr = aList.begin().get();
B* bPtr = dynamic_cast<B*>(aPtr);
// => bPtr = nullptr

This is only when libc++_shared is used.

I've tested with libc++_static, gnustl_shared & gnustl_static - the problem does not appear.
bPtr as expected is a pointer to object B added to list.

Any ideas?

Environment Details

• NDK Version: 16.0.4293906-beta1
• Build sytem: ndk-build + cmake + standalone toolchain
• Host OS: Ubuntu 16.04
• Compiler: clang c++14
• ABI: arm64-v8a
• STL: libc++_shared
• NDK API level: 21
• Device API level: 26

[andreya108]

Just tested: the same behavior when compiled with r15c.

[andreya108]

Sorry, at first I've looked at another part of code and wrote about smart pointers, but it is std::list. Description is fixed now.

[DanAlbert]

Your test case is not valid C++. Could you upload a test case?

[andreya108]

I'm trying to reproduce the problem outside our environment...

[andreya108]

I still have no luck reproducing the issue outside our environment.
Everything looks like if -fno-rtti is enabled.

Here is clang invocation command:

/usr/bin/ccache /home/andrey/android-ndk-r16-beta1/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ 
-MMD -MP -MF ./obj/local/arm64-v8a/objs-debug/src/file.o.d -gcc-toolchain /home/andrey/android-ndk-r16-beta1/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 
-target aarch64-none-linux-android -ffunction-sections -funwind-tables -fstack-protector-strong 
-fpic -Wno-invalid-command-line-argument -Wno-unused-command-line-argument 
-no-canonical-prefixes -g -fno-exceptions -fno-rtti -O0 -UNDEBUG -fno-limit-debug-info 
-I/home/andrey/android-ndk-r16-beta1/sources/cxx-stl/llvm-libc++/include 
-I/home/andrey/android-ndk-r16-beta1/sources/cxx-stl/llvm-libc++/../llvm-libc++abi/include 
-I/home/andrey/android-ndk-r16-beta1/sources/android/support/include -std=c++11 
-DUSE_ANDROID_UNIFIED_HEADERS -fcolor-diagnostics -frtti -fexceptions -femulated-tls 
-std=c++14 -fstack-protector-strong -DANDROID_NDK_VERSION=16 -Werror=return-type 
-ffunction-sections -fdata-sections -fvisibility=hidden -D_LIBCPP_HAS_NO_OFF_T_FUNCTIONS 
-fcolor-diagnostics -Wno-deprecated-register -Wno-inline-new-delete 
-Wno-invalid-source-encoding -Wno-unused-value -Wno-parentheses -Wno-deprecated 
-DANDROID -D__ANDROID_API__=21 -Wa,--noexecstack -Wformat -Werror=format-security 
-O -g -DNDEBUG --sysroot /home/andrey/android-ndk-r16-beta1/sysroot 
-isystem /home/andrey/android-ndk-r16-beta1/sysroot/usr/include/aarch64-linux-android 
-c /mnt/ssd2/Development/file.cpp -o ./obj/local/arm64-v8a/objs-debug/file.o

Can it be configured without flags overriding? I mean it inserts some default options like -fno-rtti and -std=c++11 and then they are overrided in Application.mk in APP_CPPFLAGS.

[DanAlbert]

For RTTI flags, the last one wins, so -frtti is in effect here. As long as you have -frtti in APP_CPPFLAGS it should be working.

If you are trying to cast something from a type in a library that's a prebuilt that was not built with RTTI, maybe that's the problem, but I don't think that's the case based on the command line above.

[andreya108]

Yes, it is definitely compiled with -frtti.

Btw, can rtti info be stripped somehow? We use -Wl,-gc-section and -Wl,
--version-script to strip all dead code and hide extra symbols.

But anyway, I my testcase I also used that options and it still cannot be reproduced.

But in debugger in production code (I can attach screenshot) code looks like:

A* a = * iter; // iter is std::list<A*>::iterator
B* b = dynamic_cast<B*>( a );

debugger shows that a is a pointer to class derived from B (B derived from A), but b anyway becomes NULL. I have no idea yet...

[andreya108]

How I can ensure that a shared library really contains rtti?

[DanAlbert]

We use -Wl,-gc-section and -Wl,--version-script to strip all dead code and hide extra symbols.

I'm pretty sure that RTTI across libraries does require exposing the RTTI data (which is no different from any other symbol), so if you're not exposing that in your version script, that's probably your issue.

How I can ensure that a shared library really contains rtti?

$ readelf -sW libfoo.so | c++filt | grep typeinfo

[andreya108]

It was really stripped.
But I've completely removed any stripping and hiding (no more version-script a and -gc-sections, all symbols are exported)... and nothing changed. dynamic_cast is still not working.
I can't get why it is ok with gnustl_shared.

How can I compare dynamic_cast implementations within gnustl & libc++? Where is actual for NDK source code located?

Another idea:
Here is a linking scheme in out project:

class StreamSocket : public NonBlockSocket -> libfoo.a (static)
libfoo.a + ...x... -> lib1.so
libfoo.a + ...y... -> lib2.so (2 shared libs both linked with the same static library)

java: System.loadLibrary( "c++_shared")
java: System.loadLibrary( "jniproxy")
libjniproxy.so -> dlopen ( lib1.so ) then dlopen( lib2.so )

It's known that dynamic_cast<StreamSocket*>() fails in lib2.so which is loaded after lib1.so
Can somehow rtti of lib1.so interfere with the same of lib2.so?

There are no dependencies between lib1.so and lib2.so and no C++ object of that type are passed. All communication is done via libjniproxy.so which is not aware about libfoo and its content.

andrey:~/build/libs/arm64-v8a$ readelf -sW lib1.so | c++filt | grep typeinfo | grep Socket
 2414: 000000000038cc20 17 OBJECT GLOBAL DEFAULT 11 typeinfo name for NonBlockSocket
 3698: 00000000004b59b0 24 OBJECT GLOBAL DEFAULT 18 typeinfo for StreamSocket
 9515: 00000000004b58b8 16 OBJECT GLOBAL DEFAULT 18 typeinfo for NonBlockSocket
 10173: 000000000038d324 15 OBJECT GLOBAL DEFAULT 11 typeinfo name for StreamSocket

andrey:~/build/libs/arm64-v8a$ readelf -sW lib1.so | c++filt | grep vtable | grep Socket
 444: 00000000004b58c8 224 OBJECT GLOBAL DEFAULT 18 vtable for StreamSocket
 6533: 00000000004b5818 160 OBJECT GLOBAL DEFAULT 18 vtable for NonBlockSocket

andrey:~/build/libs/arm64-v8a$ readelf -sW lib2.so | c++filt | grep typeinfo | grep Socket
 5015: 0000000000d19d88 16 OBJECT GLOBAL DEFAULT 18 typeinfo for NonBlockSocket
 17807: 00000000009f5580 17 OBJECT GLOBAL DEFAULT 11 typeinfo name for NonBlockSocket
 19740: 00000000009f5c68 15 OBJECT GLOBAL DEFAULT 11 typeinfo name for StreamSocket
 20106: 0000000000d19e80 24 OBJECT GLOBAL DEFAULT 18 typeinfo for StreamSocket

andrey:~/build/libs/arm64-v8a$ readelf -sW lib2.so | c++filt | grep vtable | grep Socket
 3601: 0000000000d19d98 224 OBJECT GLOBAL DEFAULT 18 vtable for StreamSocket
 13639: 0000000000d19ce8 160 OBJECT GLOBAL DEFAULT 18 vtable for NonBlockSocket