| 129ec188 | 03-Jul-2023 |
Kudo Chien <[email protected]> |
[go] Fix hermes inspector crash from vscode-expo (#23271)
# Why
when vscode-expo sending the `Runtime.callFunctionOn` event, it will crash ios expo go.
close ENG-9172
# How
compared this o
[go] Fix hermes inspector crash from vscode-expo (#23271)
# Why
when vscode-expo sending the `Runtime.callFunctionOn` event, it will crash ios expo go.
close ENG-9172
# How
compared this on top of expo-go and expo-dev-client, both reaching the line `throw std::runtime_error("unknown object id " + objId);`. only expo-go will crash the app because the exception is not caught. this happens on the new expo-go, even the older sdks (that's why this pr includes to backporting changes).
as the comment said, i still not figure out why the `std::runtime_error` is not caught by the `std::exception`. but the trick works
# Test Plan
ios expo go + sdk49 + vscode-expo debugging
show more ...
|
| e0f520f5 | 19-Oct-2022 |
Kudo Chien <[email protected]> |
[packages] Fix expo-modules-core androidTest (#19559)
# Why
follow up with #19411 to make expo-modules-core androidTest correctly
# How
those commented test cases break because we try to ca
[packages] Fix expo-modules-core androidTest (#19559)
# Why
follow up with #19411 to make expo-modules-core androidTest correctly
# How
those commented test cases break because we try to catch exceptions across shared library boundaries. there are a couple root causes actually:
## incompatible ndk versions
before ndk r23, the unwind library is libgcc, and after r23, the implementation is llvm libunwind. these two unwind implementation is incompatible. [email protected] and prebuilt react-native libs are all built from ndk r21. if we run the androidTest on m1 machine, we will use ndk r24 to build libraries. that's why we cannot catch fbjni exceptions in this situation. the pr tries to re-implement fbjni method calls and throw exceptions inline. that would make jni exceptions catchable.
other than that, when targeting prebuilt react-native, we should also use the same ndk r21 to build expo-modules-core. even we are on m1 machines.
## jscexecutor missing `_Unwind_Resume` symbol
the case happens when ndk r21 + jsc only, and this is also our ci android instrumented test environment. as [the ndk document](https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md#unwinding) mentioned, for ndk r21, we should take care linking order. [this react-native fork patch](https://github.com/expo/react-native/commit/3986a385502df3eb207ca05f0b558171a600166c) addressed the issue.
if we test jsc on bare-expo, these test cases will still crash. i don't want to fix it or proposing the fix to upstream in the meantime. the latest react-native with AGP 7.3, the side-by-side ndk is already r23. since these are actually error cases, it's just not crash with correct stacktrace (not from expo-modules-core, but jscexecutor)
## c++_static runtime in expo-modules-core androidTest
always uses c++_shared runtime: the c++_static runtime doesn't well support the throw exceptions between shared library boundaries. we used c++_static because we want to fix the `et android-native-unit-tests -t instrumented` failures where the `./gradlew :expo-modules-core:connectedAndroidTest :expo-eas-client:connectedAndroidTest` will have duplicated fbjni.so build errors. this pr also reorganizes `et android-native-unit-tests` to build expo-modules-core androidTest exclusively.
# Test Plan
android instrumented ci passed
show more ...
|