We're experiencing a similar crash in our app after upgrading React Native from 0.61.5 to 0.63.2. While we are not using tesseract, we have our own C++ libraries which have worked fine before. After updating, we are experiencing a std::bad_cast exception in the yaml-cpp library originating from this line, which also uses a basic stringstream operation. In lldb I could verify that key is a valid, null-terminated char array, so the error appears to originate from the standard library itself. The problem persisted after linking against React Native's NDK version (19.2.5345600).
Interestingly, we were able to 'resolve' the issue by also statically linking our library against the stl (setting the CMake parameter ANDROID_STL=c++_static), after which no exception is thrown and our code appears to run as expected. We have yet to test on a device outside of the simulator.
Could the libc++_shared.so be broken somehow?

I am also facing the same issue on 0.62 and above. Although it seems to be working on 0.61.5 as commented above. I am using an android library which also contains the native libC++_shared.so. I have also checked with the latest NDK, but that does not solve the issue with 0.62 and above.

Waiting for a solution on this.

Hi,
Also experiencing similar issues. Using std such as stringstream stopped working, and causing crashes.
It was working fine when using 0.61.
Hoping to get this fixed.
Thank you.

Any update about this issue?
I get the same issue with "react-native": "0.62.2", anyone can help me resolve this issue?
Thank you!

@Nikituh Can you share your script, file and steps to fix this issue at the moment?

FYI, I can confirm that for us statically linking against the STL (e.g. by passing the CMake parameter ANDROID_STL=c++_static) solved the issue for us in simulator and on-device.

@TheLartians Can you give me more detail? I mean steps to do it to resolve this issue. Thank you

Sure, though I'm not sure if this will be of much use to you, as we fixed the issue for our own self-maintained C++ library and don't use tesseract or derived projects. We simply added the following line to the gradle script, which is responsible for calling CMake.

    externalNativeBuild {
      cmake {
        arguments.add("-DCMAKE_BUILD_TYPE=Release")
+       arguments.add("-DANDROID_STL=c++_static")
        targets.add("path/to/CMake/project")
      }
    }

By statically linking against the STD, our library will not use the libc++_shared.so that is used by React Native, which fixed the crash for us. I guess a similar patch could temporarily fix tesseract as well, but I don't really know how it's built for React Native.

@TheLartians Thank you, I had to try it, it's no more crash but the app always reopens and not work as well. I think I'll downgrade to RN 0.61 and waiting for RN fix this problem!

The problem may come from conflict version of libc++_shared.so (between r20 and r21)

scanbot sdk bundled libc++_shared.so with ndk r21.
checked from the sdk 1.70.1 here

react native 0.62/0.63 bundled with ndk r20

some suggestion to add packagingOptions.pickFirst in build.gradle, but the reality is that which libc++_shared.so to be picked is uncertain.
that's why i proposed to remove packagingOptions.pickFirst in react native template after 0.63.

even as far as i know, ndk maintains ABI stability well between updates.
don't know what happened between ndk r20 and r21.
the formal solution might be to build react native from source with ndk r21 + pickFirst (assuming scanbot sdk cannot build from source).
but if what @Nikituh mention that react native 0.64 fixed the problem, maybe ndk fixed the compatibility issue after r20b (react native 0.64 bump ndk to r20b)

Hi,

In the past weeks, I tried to investigate the issue, and apparently, the only solution for it (unless Facebook solves the issue before) is to build your native code using the static version of libc++.

In addition, I kept looking for workarounds, and today I found a one, which some of you (including me) will call dirty or nasty - but it works.
I am sharing it with you so can provide your opinions on it (and maybe use it too...), and MORE: explain why it works and whether it could affect RN's functionality:

In the method onCreate() of the RN's class MainApplication.java was changed so its first action is loading libc++_shared.so to the app's memory before any other library RN's code loads:

From:

@Override
  public void onCreate() {
    super.onCreate();
    SoLoader.init(this, /* native exopackage */ false);
    initializeFlipper(this, getReactNativeHost().getReactInstanceManager());
  }

To:

@Override
  public void onCreate() {
    System.loadLibrary("c++_shared");
    super.onCreate();
    SoLoader.init(this, /* native exopackage */ false);
    initializeFlipper(this, getReactNativeHost().getReactInstanceManager());
  }

The reason I took the liberty to make this change is that this class must change whenever a Native module is added to the RN class (See RN's documentation https://reactnative.dev/docs/0.61/native-modules-android#register-the-module) ...

In order to test the change, I used two examples:

1. The sample code that fails, which is included in the issue's description (with some minor adaptations...) -
   (Verified that the substring "NULL" from buffer is no successfully assigned to unichar)

const char* buffer = "NULL 0 NULL 0\n";
std::istringstream stream(buffer);
stream.imbue(std::locale::classic());
// 标 1 0,255,0,255,0,0,0,0,0,0 Han 68 0 68 标  # 标 [6807 ]x
stream >> std::setw(255) >> unichar >> std::hex >> properties >> std::dec;

2. A conversion from a string to a number, which failed In my company's code:

std::string in_str_ = "1234"; 
   double out_number_ = 0.0;
   std::istringstream iss(in_str_);
   iss >> out_number_;

Thanks
Shay

Hi @Kudo,

Last week I found a workaround to the above failure - by explicitly loading libc++_shared.so before RN loads its own Native Shared Libraries.
This change does not require any other change and was verified on different RN apps.

If the issue is still relevant for you, I will be more than happy to have your comments on it.
Thanks
Shay

@Zshay2203 , you're a rockstar. Though I am still struggling to figure out the future impacts with react native after applying this fix. Do you have any updates on this?

@Zshay2203 , you're a rockstar. Though I am still struggling to figure out the future impacts with react native after applying this fix. Do you have any updates on this?

@murtazabeans, You've got me, I am actually Elvis Presley ...
Thanks for the compliment!

Regarding your question, a couple of customers of the company I am working for have applied the workaround in their app without any side effects.

Thinking logically, I really don't think this fix should have any side effect on RN's functionality for the following reasons:

1. As stated in the issue's description, a call to a steam's ">>" operator fails due to a missing facet. Using Android
   Studio's debugger, I reached the point of failure: Attempt to read an invalid value, which is stored in _Facet::id -
   in the file: __locale under /sources/cxx-stl/llvm-libc++/include:

template <class _Facet>
inline _LIBCPP_INLINE_VISIBILITY
const _Facet&
use_facet(const locale& __l)
{
    return static_cast<const _Facet&>(*__l.use_facet(_Facet::id));
}

My 100% guess is that RN's c++ code sets a locale with it starts when it does not have a specific value, and probably deallocates but its reference is stored in _Facet::id.

2. Since the failure lies deep inside a commonly used C++ STL code and ONLY the C++ of RN Bridges is affected by it and not a C++ code of RN then I can conclude that RN does not use it at all.

It would be great if one of RN's developers could comment on that.

thanks again
Shay

@Zshay2203 , I think react native team should update the NDK. Currently the ndk used by react native is 20.1.5948944 which is marked as Unsupported type. It will resolve the problem if the ndk is updated sometime in future.

I have opened a bug on their team for this - #31701

Here still waiting for the fix from RN. I have issue with amazon-chime-sdk

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

This issue was closed because it has been stalled for 7 days with no activity.