"pure virtual method called" when using std::thread with clang in NDK r12b

[petya2164]

I have a runtime issue with the following std::thread example (thread.cpp):

#include <iostream>
#include <thread>

void function()
{
  std::cerr << "thread\n";
}

int main (int argc, char * argv [])
{
  std::cerr << "starting\n";
  std::thread thr(function);
  std::cerr << "joining\n";
  thr.join();
  std::cerr << "done\n";
  return 0;
}

If I compile the example with clang in NDK r12b (using a standalone toolchain):
arm-linux-androideabi-clang++ -std=c++11 -march=armv7-a thread.cpp -o thread
I get the following runtime failure on various Android devices (I tried Android 4.0, 4.4 and 6.0):

starting
pure virtual method called
joining
terminate called without an active exception
Segmentation fault

If I compile with g++ (from the same standalone toolchain):
arm-linux-androideabi-g++ -std=c++11 -march=armv7-a thread.cpp -o thread
Then I get the expected output on all devices:

starting
joining
thread
done

Clang had a similar issue in the past: https://llvm.org/bugs/show_bug.cgi?id=12730
An incorrect g++ configuration led to the same issue on ARM: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
Any ideas for a fix?

[DanAlbert]

Which STL?

[petya2164]

I used the default STL, I just checked that the default is gnustl in make_standalone_toolchain.py.
The toolchain was created like this:
python make_standalone_toolchain.py --arch arm --api 9

Is it recommended to use libc++ instead for clang?
Is it supposed to be feature-complete and stable on Android?

[DanAlbert]

gnustl is a safer bet than the libc++ we have in the NDK right now. libc++ is getting closer, but we're not really to the point that I'm happy recommending it yet. It's a useful data point for reproducing the error though, and we've definitely seen cases where clang and gnustl don't get along in some of the C++11 parts of the library (typically atomic and type_traits, but I think we've seen thread issues too).

https://llvm.org/bugs/show_bug.cgi?id=12730#c10 seems to be the really interesting piece, but according to the following messages on that bug it should be fixed...

I'll do a bit of digging to make sure all those pieces are on for Android.

[DanAlbert]

Interestingly I don't see this problem if I use ndk-build, only via standalone toolchains.

[DanAlbert]

Found the issue, and it's actually one I've reported before (internally).

The problem is that Clang doesn't search subarchitecture directories when linking libraries. Instead of passing -L toolchain/arm-linux-androideabi/lib/armv7-a to the linker, it passes toolchain/arm-linux-androideabi/lib (the arm5 directory), which results in the same bug you linked in your initial report (good find, btw).

Since using ndk-build doesn't have the toolchain in the standard GCC cross compiler layout, the default directories aren't used and the library is just linked manually.

Clang was recently fixed upstream, so once we can update Clang this will be resolved.

Unfortunately, Clang has moved to new enough Windows APIs that we can't actually build Clang until we sort some things out in our build infrastructure, so I don't know how soon that will be.

To workaround this until then you can pass -L toolchain/arm-linux-androideabi/lib/armv7-a manually when building for armv7 (no other ABI will have this problem). It's a pain, but it should at least get you moving until we get Clang updated again.

[petya2164]

Thank you very much for finding the root cause of the issue!
I can confirm that passing -L toolchain/arm-linux-androideabi/lib/armv7-a solves the problem. Good to hear that clang was already patched and the fix will be included in the next update.

In the meantime, I also encountered a linker issue with this std::future example:

#include <iostream>
#include <future>

int main()
{
  std::future<int> f1 = std::async([](){ return 42; });
  f1.wait();
  std::cout << "Magic number is: " << f1.get() << std::endl;
  return 0;
}

And the same workaround fixes that problem as well!
So this can be a remedy for other STL-related issues.

[stephenhines]

Just to be pedantic, the clang fix is not in any scheduled NDK update yet. We hope to get it into a future release, but Windows issues are blocking that.

[petya2164]

This issue is still present with NDK r13b (considering the standalone toolchain). Do you have any updates about the Windows issues that you mentioned above?

[DanAlbert]

The Windows toolchain issues are fixed and we have an updated Clang in r14. @stephenhines should be able to confirm that we have this fix (I think we do, but I'm not 100% certain).

This is available in the canary builds if you're feeling brave (although the beta should be published in a few hours, or so I'm told): https://android.googlesource.com/platform/ndk/+/master/docs/ContinuousBuilds.md

[stephenhines]

This is likely fixed, but awaiting verification.

[petya2164]

I can confirm that this issue is fixed in r14. It is now safe to use clang as a standalone toolchain. I will close this issue.