Crash in ARM64 app linked with gnustl/arm64-v8a/libgpg.a

[chrisbabcock-epic]

We recently updated to Google Play Game native C++ SDK 2.1 from 1.1 and it now has libraries for ARM64 so I enabled the gnustl one lib/gnustl/arm64-v8a/libgpg.a. I have tested NDK r11c and r12b.

Just linking this library is causing a crash during the initialization during dlopen. I was able to trace it to gpg::proto::AchevementImpl::SharedCtor()() with GDB. Here is the GDB callstack:

[0x0000007F88B0453C] libUE4.so!gpg::proto::AchievementImpl::SharedCtor()()  C++
[0x0000007F88B045F4] libUE4.so!gpg::proto::protobuf_AddDesc_achievement_5fimpl_2eproto()()  C++
[0x0000007FA432ECF8] linker64!__dl__ZN6soinfo13call_functionEPKcPFvvE() C++
[0x0000007FA432EE4C] linker64!__dl__ZN6soinfo10call_arrayEPKcPPFvvEmb() C++
[0x0000007FA43350D8] linker64!__dl__Z9do_dlopenPKciPK17android_dlextinfo()  C++
[0x0000007FA432E440] linker64!__dl_dlopen() C++
[0x0000007FA005AC34] libart.so!art::JavaVMExt::LoadNativeLibrary(_JNIEnv*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, _jobject*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)()   C++
[0x0000007FA00FA3A8] libart.so!art::Runtime_nativeLoad(_JNIEnv*, _jclass*, _jstring*, _jobject*, _jstring*)()   C++

Here is the disassembly:

0x0000007F88B0453C ldr x1, [x1,#20928]
0x0000007F88B04540 str x1, [x0,#8]
0x0000007F88B04544 str x1, [x0,#16]
0x0000007F88B04548 str x1, [x0,#24]
0x0000007F88B0454C str w2, [x0,#32]
0x0000007F88B04550 str w2, [x0,#36]
0x0000007F88B04554 str wzr, [x0,#40]
0x0000007F88B04558 str wzr, [x0,#44]
0x0000007F88B0455C str xzr, [x0,#48]
0x0000007F88B04560 str x1, [x0,#56]
0x0000007F88B04564 str x1, [x0,#64]
0x0000007F88B04568 str xzr, [x0,#72]
0x0000007F88B0456C str wzr, [x0,#84]
0x0000007F88B04570 ret

And the registers:

x0 = 0x0000007f99cfd440 x1 = 0x0000007f8f7b9000 x2 = 0x0000000000000001 x3 = 0x0000000000000010 x4 = 0x0000000000000000 x5 = 0x0000000000004001 x6 = 0x0000000000000000 x7 = 0xcdcdcdcdcdcdcdcd x8 = 0x0000007f99cfd498 x9 = 0x0000000000000916 x10 = 0x0000007f9ed40318 x11 = 0x0000000000004000 x12 = 0x0000000000004001 x13 = 0x0000000000000000 x14 = 0x0000000000000001 x15 = 0x00000000002a6570 x16 = 0x0000007f8a588d48 x17 = 0x0000007fa3e979c0 x18 = 0x000000000000002b x19 = 0x0000007f99cfd440 x20 = 0x0000007f85b24ce8 x21 = 0x0000007fa4351458 x22 = 0x0000007fa436e000 x23 = 0x0000007fa4351458 x24 = 0x0000007fa4351440 x25 = 0x0000007fa4351250 x26 = 0x00000000000001c1 x27 = 0x0000007fa436ea20 x28 = 0x0000007fa43514f0 x29 = 0x0000007ff998d580 x30 = 0x0000007f88b045f4 sp = 0x0000007ff998d570
pc = 0x0000007f88b0453c cpsr = 0x80000000

Anyone else seeing this, or have any suggestions?

[claywilkinson]

Thanks for posting here - I'll pass it along to the SDK team as well.

[claywilkinson]

This issue has been addressed and I have confirmed it fixed in version 3.0 of the C++ SDK.