-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] ndk-build unhandled exception #1043
Comments
Maybe for ndk-build, APP_STL is defined differently. |
Both are using c++_static. You can confirm the same with the sample I have shared. It consists of multiple modules and product flavours for each configuration.
When RTTI is enabled, the same code works for CMake builds despite the loading sequence of native libraries. But, it crashes with ndk-build. |
It's not safe to use static STL when different libraries pass C++ objects
one to the other, including exceptions. Essentially, you now have two
independent runtime frameworks, and their housekeeping may fail. It's not
an immediate disaster, as when you try to mix stlport with gnustl, but
having a latent vulnerability that may get triggered by some circumstances
beyond your control, is even worse.
Try to build your app with c++_shared.
BR,
Alex
|
Thanks for the suggestions. We have a larger project that uses c++_static and ndk-build at the moment and it is the only STL used throughout the project. I wonder how CMake manages to build the libs properly while ndk-build fails. I just compared the type info of resulted libraries. CMake build doesn't have any duplicates on the FirstLib and produces 73% smaller library. TypeInfo for CMake build
TypeInfo for ndk-build
TypeInfo of SecondLib is identical in both builds. Could it be something related to the order of linking on ndk-build? |
Added ndk-build:
CMake:
Note specifically how libSecondLib.so is linked very early with CMake, but in the appropriate place with ndk-build. This is causing FirstLib to (incorrectly) load most of libc++/libc++abi from SecondLib, which is preventing you from having multiple copies of the typeinfo for the standard library exceptions in your application. In this case this behavior is actually helping you, but this behavior can cause other issues (see any of the many threads here on crashes with arm32 exception handling caused by loading the unwinder from the wrong library).
The good news is that, like @alexcohn initially guessed, this should work for both systems once you get around to switching to libc++_shared. Like he says, using libc++_static when you have more than one shared library is something you really shouldn't do, specifically because it gets you into weird problems like this. Closing because I think we have the diagnosis here. ndk-build links correctly, but the build as specified includes ODR violations. CMake doesn't link correctly and in doing so accidentally avoids the ODR violation. CMake linking order being wrong is not anything to do with the NDK, and can't realistically be fixed because it would require altering the behavior of upstream CMake. |
Wouldn't it be prudent to set |
That's what Reopening this to track that. I can't think of any problems off the top of my head. |
Testing this now for libc++_static.a, libc++abi.a, and libunwind.a. We already had this for libandroid_support.a. If that goes well it may be worth doing for libgcc.a as well. |
That actually doesn't change much, since these libraries (quite reasonably) mark their API with |
This is yet another report of unhandled exception while using libc++ and more or less same as #533 or #519
The project consists of 2 native libs where the first library will call a function on the second library. When there is an exception, it will try to catch it. When ndk-build is used to build the native libs (even with rtti), the exception is not handled if the second library loaded prior to the first one. But, the same is properly handled when CMake is used to build the libs (except when rtti is disabled).
It looks like ndk-build misses some flags or passing some flags that can cause this issue.
Sample:
https://drive.google.com/open?id=1C3MefjGn0h1uQKC-JThuTrmIpfxjhb1Y
Environment Details
The text was updated successfully, but these errors were encountered: