iOS crash, only release from testflight or archive build

[mtostenson]

🐛 Bug Report

Crash on launch. Here is the relevant log:

Thread 6 Crashed:
0   libsystem_kernel.dylib        	0x00000002388a5104 __pthread_kill + 8
1   libsystem_pthread.dylib       	0x0000000238924a00 pthread_kill$VARIANT$armv81 + 296
2   libsystem_c.dylib             	0x00000002387fcd78 abort + 140
3   libsystem_malloc.dylib        	0x00000002388f9768 _malloc_put + 0
4   libsystem_malloc.dylib        	0x00000002388f9924 malloc_report + 64
5   libsystem_malloc.dylib        	0x00000002388ec2d0 free + 376
6   libc++.1.dylib                	0x0000000237ea7120 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string+ 258336 () + 32
7   ExampleApp                 	0x00000001053cd494 std::__1::__vector_base<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::~__vector_base() + 5264532 (vector:451)
8   ExampleApp                 	0x00000001059c8f04 facebook::react::ModuleRegistry::getConfig+ 11538180 (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 100
9   ExampleApp                 	0x00000001059d7e58 facebook::react::JSCNativeModules::createModule+ 11599448 (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, OpaqueJSContext const*) + 292
10  ExampleApp                 	0x00000001059d79b8 facebook::react::JSCNativeModules::getModule+ 11598264 (OpaqueJSContext const*, OpaqueJSString*) + 188
11  ExampleApp                 	0x00000001059d254c OpaqueJSValue const* (*facebook::react::(anonymous namespace)::exceptionWrapMethod<&(facebook::react::JSCExecutor::getNativeModule(OpaqueJSValue*, OpaqueJSString*))>())(OpaqueJSContext const*, OpaqueJSValue*, OpaqueJSString*, OpaqueJSValue const**)::funcWrapper::call+ 11576652 (OpaqueJSContext const*, OpaqueJSValue*, OpaqueJSString*, OpaqueJSValue const**) + 104
12  JavaScriptCore                	0x0000000240038404 JSC::JSCallbackObject<JSC::JSDestructibleObject>::getOwnPropertySlot+ 574468 (JSC::JSObject*, JSC::ExecState*, JSC::PropertyName, JSC::PropertySlot&) + 340
13  JavaScriptCore                	0x000000024071d4f0 llint_slow_path_get_by_id + 2008
14  JavaScriptCore                	0x0000000240010928 llint_entry + 11528
15  JavaScriptCore                	0x0000000240015134 llint_entry + 29972
16  JavaScriptCore                	0x0000000240015134 llint_entry + 29972
17  JavaScriptCore                	0x0000000240015134 llint_entry + 29972
18  JavaScriptCore                	0x0000000240015134 llint_entry + 29972
19  JavaScriptCore                	0x0000000240015134 llint_entry + 29972
20  JavaScriptCore                	0x000000024000da1c vmEntryToJavaScript + 300
21  JavaScriptCore                	0x0000000240683fe4 JSC::Interpreter::executeProgram+ 7176164 (JSC::SourceCode const&, JSC::ExecState*, JSC::JSObject*) + 9620
22  JavaScriptCore                	0x000000024085f218 JSC::evaluate+ 9122328 (JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&) + 316
23  JavaScriptCore                	0x0000000240036634 JSEvaluateScript + 472
24  ExampleApp                 	0x00000001059b17c0 facebook::react::evaluateScript+ 11442112 (OpaqueJSContext const*, OpaqueJSString*, OpaqueJSString*) + 80
25  ExampleApp                 	0x00000001059d0608 facebook::react::JSCExecutor::loadApplicationScript+ 11568648 (std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 528
26  ExampleApp                 	0x00000001059d6894 std::__1::__function::__func<facebook::react::NativeToJsBridge::loadApplication(std::__1::unique_ptr<facebook::react::RAMBundleRegistry, std::__1::default_delete<facebook::react::RAMBundleRegistry> >, std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::$_0, std::__1::allocator<facebook::react::NativeToJsBridge::loadApplication(std::__1::unique_ptr<facebook::react::RAMBundleRegistry, std::__1::default_delete<facebook::react::RAMBundleRegistry> >, std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::$_0>, void (facebook::react::JSExecutor*)>::operator()+ 11593876 (facebook::react::JSExecutor*&&) + 144
27  ExampleApp                 	0x00000001059d7898 std::__1::function<void (facebook::react::JSExecutor*)>::operator()+ 11597976 (facebook::react::JSExecutor*) const + 40
28  ExampleApp                 	0x000000010594b5a8 facebook::react::tryAndReturnError(std::__1::function<void + 11023784 ()> const&) + 24
29  ExampleApp                 	0x0000000105941104 facebook::react::RCTMessageThread::tryFunc(std::__1::function<void + 10981636 ()> const&) + 24
30  CoreFoundation                	0x0000000238c9e408 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20
31  CoreFoundation                	0x0000000238c9dd08 __CFRunLoopDoBlocks + 272
32  CoreFoundation                	0x0000000238c99220 __CFRunLoopRun + 2376
33  CoreFoundation                	0x0000000238c985b8 CFRunLoopRunSpecific + 436
34  ExampleApp                 	0x0000000105922280 +[RCTCxxBridge runRunLoop] + 264
35  Foundation                    	0x00000002397bf3b0 __NSThread__start__ + 1040
36  libsystem_pthread.dylib       	0x00000002389292fc _pthread_body + 128
37  libsystem_pthread.dylib       	0x000000023892925c _pthread_start + 48
38  libsystem_pthread.dylib       	0x000000023892cd08 thread_start + 4

I have been able to narrow it down to this function: ModuleRegistry::moduleNames
When the vector that is returned from this function goes out of scope and the memory is freed, the app inexplicably crashes. I have been able to work around this by adding a field to ModuleRegistry.h that stores the value returned from moduleNames, and in doing so the memory is not freed and the app continues to run as normal. I find it odd that moduleNames() returns a vector that is not stored anywhere, was this intended?

To Reproduce

I'm using React Native 0.57.3, but the latest version does not have any changes in the ModuleRegistry class where the issue seems to be happening. I am using a third party library that includes a custom RCTBridgeModule. It behaves normally until we do a beta on testflight or a local archive.

Expected Behavior

I would not expect the app to crash on launch.

Environment

React Native Environment Info:
System:
OS: macOS High Sierra 10.13.6
CPU: (8) x64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
Memory: 50.11 MB / 16.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 10.14.1 - ~/.nvm/versions/node/v10.14.1/bin/node
npm: 6.4.1 - ~/.nvm/versions/node/v10.14.1/bin/npm
Watchman: 4.6.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.0, macOS 10.14, tvOS 12.0, watchOS 5.0
Android SDK:
API Levels: 23, 25, 26, 27, 28
Build Tools: 23.0.1, 25.0.2, 25.0.3, 26.0.1, 26.0.2, 26.0.3, 27.0.1, 27.0.3, 28.0.3
System Images: android-27 | Google Play Intel x86 Atom
IDEs:
Android Studio: 3.2 AI-181.5540.7.32.5056338
Xcode: 10.0/10A255 - /usr/bin/xcodebuild
npmPackages:
react: 16.6.0-alpha.8af6728 => 16.6.0-alpha.8af6728
react-native: 0.57.3 => 0.57.3
npmGlobalPackages:
react-native-ar: 2.0.0-test19
react-native-cli: 2.0.1
react-native-unity-view: 1.3.2
solidarity-react-native: 2.0.2

[react-native-bot]

It looks like you are using an older version of React Native. Please update to the latest release, v0.58 and verify if the issue still exists.

The "Resolution: Old Version" label will be removed automatically once you edit your original post with the results of running react-native info on a project using the latest release.

[hramos]

Just to set expectations, we rarely track individual crashes in this repository, with the exception of reports where there are clear repro steps (i.e. a small sample project that shows the crash). As it happens, debugging individual crashes in any particular application is something that is very likely out of reach for any one in this repo other than yourself.

[mtostenson]

@hramos Thanks for the reply, but in my description I outlined a possible issue on the ModuleRegistry class, I was hoping to get some discussion around that point.

[JanOwiesniak]

@hramos just to let you know:

I'm running into a similar issue with iPhone XS MAX iOS 12.1.4 in a project that is unrelated to @mtostenson's project. Using https://github.com/f111fei/react-native-unity-view as well.

  React Native Environment Info:
    System:
      OS: macOS High Sierra 10.13.6
      CPU: x64 Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz
      Memory: 592.68 MB / 16.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 8.15.0 - /usr/local/opt/node@8/bin/node
      Yarn: 1.13.0 - /usr/local/bin/yarn
      npm: 6.4.1 - /usr/local/opt/node@8/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
      Android SDK:
        Build Tools: 23.0.1, 26.0.2, 27.0.1, 27.0.3, 28.0.1, 28.0.3
        API Levels: 21, 23, 24, 25, 26, 27, 28
    IDEs:
      Android Studio: 3.3 AI-182.5107.16.33.5199772
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.5.0 => 16.5.0
      react-native: 0.57.0 => 0.57.0
    npmGlobalPackages:
      react-native-cli: 2.0.1
      react-native-git-upgrade: 0.2.7

[hramos]

Thanks for the additional detail. I'm re-opening due to the original author's desire to discuss potential causes, but I retain my stance that investigating individual crashes in different projects is unlikely to be fruitful in this repository. I'm unsubscribing from notifications for this thread.

[lklepner]

We are experiencing a similar crash in 0.57.8 that also seems attributable to memory management in some fashion. Approximately 4% of our app launches experience the crash below within 2 seconds of the app booting.

Exception Type:  SIGSEGV
Exception Codes: SEGV_MAPERR at 0xc500b9f1df40
Crashed Thread:  1

React Exception Stack:

Thread 1 Crashed:
0   Bright                               0x000000010288d648 facebook::react::Instance::loadApplication(std::__1::unique_ptr<facebook::react::RAMBundleRegistry, std::__1::default_delete<facebook::react::RAMBundleRegistry> >, std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 40
1   Bright                               0x000000010288d96c facebook::react::Instance::loadScriptFromString(std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool) + 196
2   Bright                               0x00000001027dfb88 __51-[RCTCxxBridge executeApplicationScript:url:async:]_block_invoke + 768
3   Bright                               0x0000000102802b44 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) + 20
4   Bright                               0x00000001027d98e0 -[RCTCxxBridge _tryAndHandleError:] + 84
5   Bright                               0x00000001027df81c -[RCTCxxBridge executeApplicationScript:url:async:] + 156
6   Bright                               0x00000001027df604 -[RCTCxxBridge enqueueApplicationScript:url:onComplete:] + 108
7   Bright                               0x00000001027dd1e4 -[RCTCxxBridge executeSourceCode:sync:] + 224
8   Bright                               0x00000001027dad30 __21-[RCTCxxBridge start]_block_invoke_2 + 92
9   libdispatch.dylib                    0x0000000193cf16c8 _dispatch_call_block_and_release + 20
10  libdispatch.dylib                    0x0000000193cf2484 _dispatch_client_callout + 12
11  libdispatch.dylib                    0x0000000193ca1b4c _dispatch_root_queue_drain + 680
12  libdispatch.dylib                    0x0000000193ca22c0 _dispatch_worker_thread2 + 124
13  libsystem_pthread.dylib              0x0000000193ed517c _pthread_wqthread + 468
14  libsystem_pthread.dylib              0x0000000193ed7cec start_wqthread + 0

@mtostenson you mentioned you had some success working around this issue - would it be possible for you to post the fix you put into place? We'd love to give it a try in our project.

I have been able to narrow it down to this function: ModuleRegistry::moduleNames
When the vector that is returned from this function goes out of scope and the memory is freed, the app inexplicably crashes. I have been able to work around this by adding a field to ModuleRegistry.h that stores the value returned from moduleNames, and in doing so the memory is not freed and the app continues to run as normal. I find it odd that moduleNames() returns a vector that is not stored anywhere, was this intended?

[JanOwiesniak]

@lklepner the fix @mtostenson mentioned above is captured in the first screenshot in this comment. Hope this helps.

[lklepner]

Many thanks @JanOwiesniak, I'll give that a try.

[zengkebing3630]

We are experiencing a similar crash in 0.57.8 that also seems attributable to memory management in some fashion. Approximately 4% of our app launches experience the crash below within 2 seconds of the app booting.

Exception Type:  SIGSEGV
Exception Codes: SEGV_MAPERR at 0xc500b9f1df40
Crashed Thread:  1

React Exception Stack:

Thread 1 Crashed:
0   Bright                               0x000000010288d648 facebook::react::Instance::loadApplication(std::__1::unique_ptr<facebook::react::RAMBundleRegistry, std::__1::default_delete<facebook::react::RAMBundleRegistry> >, std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 40
1   Bright                               0x000000010288d96c facebook::react::Instance::loadScriptFromString(std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool) + 196
2   Bright                               0x00000001027dfb88 __51-[RCTCxxBridge executeApplicationScript:url:async:]_block_invoke + 768
3   Bright                               0x0000000102802b44 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) + 20
4   Bright                               0x00000001027d98e0 -[RCTCxxBridge _tryAndHandleError:] + 84
5   Bright                               0x00000001027df81c -[RCTCxxBridge executeApplicationScript:url:async:] + 156
6   Bright                               0x00000001027df604 -[RCTCxxBridge enqueueApplicationScript:url:onComplete:] + 108
7   Bright                               0x00000001027dd1e4 -[RCTCxxBridge executeSourceCode:sync:] + 224
8   Bright                               0x00000001027dad30 __21-[RCTCxxBridge start]_block_invoke_2 + 92
9   libdispatch.dylib                    0x0000000193cf16c8 _dispatch_call_block_and_release + 20
10  libdispatch.dylib                    0x0000000193cf2484 _dispatch_client_callout + 12
11  libdispatch.dylib                    0x0000000193ca1b4c _dispatch_root_queue_drain + 680
12  libdispatch.dylib                    0x0000000193ca22c0 _dispatch_worker_thread2 + 124
13  libsystem_pthread.dylib              0x0000000193ed517c _pthread_wqthread + 468
14  libsystem_pthread.dylib              0x0000000193ed7cec start_wqthread + 0

@mtostenson you mentioned you had some success working around this issue - would it be possible for you to post the fix you put into place? We'd love to give it a try in our project.

I have been able to narrow it down to this function: ModuleRegistry::moduleNames
When the vector that is returned from this function goes out of scope and the memory is freed, the app inexplicably crashes. I have been able to work around this by adding a field to ModuleRegistry.h that stores the value returned from moduleNames, and in doing so the memory is not freed and the app continues to run as normal. I find it odd that moduleNames() returns a vector that is not stored anywhere, was this intended?

I also encountered the same crash, positioning the problem is to get the resource is not RAMBundle. I am suspecting that the test environment problem when the device is coordinated

Crashed: com.apple.root.user-interactive-qos
0 ZuZuCheIOS 0x1011a046c facebook::react::Instance::loadApplication(std::__1::unique_ptr<facebook::react::RAMBundleRegistry, std::__1::default_deletefacebook::react::RAMBundleRegistry >, std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >) + 61 (Instance.cpp:61)
1 ZuZuCheIOS 0x1011a0790 facebook::react::Instance::loadScriptFromString(std::__1::unique_ptr<facebook::react::JSBigString const, std::__1::default_delete<facebook::react::JSBigString const> >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, bool) + 1406 (string:1406)
2 ZuZuCheIOS 0x1011def64 __51-[RCTCxxBridge executeApplicationScript:url:async:]_block_invoke + 1406 (string:1406)
3 ZuZuCheIOS 0x1011e36a4 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) (RCTCxxUtils.mm)
4 ZuZuCheIOS 0x1011d929c -[RCTCxxBridge _tryAndHandleError:] + 257 (RCTCxxBridge.mm:257)
5 ZuZuCheIOS 0x1011dec60 -[RCTCxxBridge executeApplicationScript:url:async:] + 1308 (RCTCxxBridge.mm:1308)
6 ZuZuCheIOS 0x1011dea4c -[RCTCxxBridge enqueueApplicationScript:url:onComplete:] + 1264 (RCTCxxBridge.mm:1264)
7 ZuZuCheIOS 0x1011dc83c -[RCTCxxBridge executeSourceCode:sync:] + 891 (RCTCxxBridge.mm:891)
8 ZuZuCheIOS 0x1011da0dc __21-[RCTCxxBridge start]_block_invoke_2 + 373 (RCTCxxBridge.mm:373)
9 libdispatch.dylib 0x1bcdbca38 _dispatch_call_block_and_release + 24
10 libdispatch.dylib 0x1bcdbd7d4 _dispatch_client_callout + 16
11 libdispatch.dylib 0x1bcd6e164 _dispatch_root_queue_drain + 680
12 libdispatch.dylib 0x1bcd6e8d4 _dispatch_worker_thread2 + 128
13 libsystem_pthread.dylib 0x1bcf9e1b4 _pthread_wqthread + 464
14 libsystem_pthread.dylib 0x1bcfa0cd4 start_wqthread + 4

[zengkebing3630]

After tracking the code, it has been confirmed that [RCTBridge invalidate] is called in the main thread, while [RCTCxxBridge executeApplicationScript:] loads resources in the dispatch_get_global_queue--QOS_CLASS_USER_INTERACTIVE thread, and the user quickly initializes and unregisters (or reloads) the RCTBridge. Causes the callback_ of Instance::loadScriptFromString in Instance.cpp to be released and still crashed. Quote the original code and annotations of Daxie

/**
    * Any thread
    */
   Dispatch_async(dispatch_get_main_queue(), ^{
     // WARNING: Invalidation is async, so it may not finish before re-setting up the bridge,
     // causing some issues. TODO: revisit this post-Fabric/TurboModule.
     [self invalidate];
     // Reload is a special case, do not preserve launchOptions and treat reload as a fresh start
     Self->_launchOptions = nil;
     [self setUp];
   });

[zengkebing3630]

我缓存了 RCTBridge，没有移除bridge，线上还报奔溃，定位到是 callback_->incrementPendingJSCalls();方法奔溃，callback_是一个Null，callback_只有初始化没有移除方法，
赋值到对象是 bridge，它肯定是存在的，那最有可能引起callback_就在
std::make_unique(self),
callback_ = std::move(callback);
两个方法中了变成NULL，奔溃的占比为1%，请协助处理下

[henrymoulton]

Many thanks @JanOwiesniak, I'll give that a try.

@lklepner did this work?

[kennym]

Many thanks @JanOwiesniak, I'll give that a try.

@lklepner did this work?

It didn't seem to work. (We work together)

[auro-krishna]

I got it (partially!). Actually "release" implementation of UI_USER_INTERFACE_IDIOM() in swift project crashes the app.

However, still I have no clue why our app store app (objective c language based) does NOT crash.

My only guess is that it's a glitch in UI_USER_INTERFACE_IDIOM() API implementation with some language specific coding (swift vs objective c) by Apple.

Anyways, I would replace all UI_USER_INTERFACE_IDIOM() with UIDevice(). userInterfaceIdiom. I hope this helps someone!

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.

[amirhosein5858]

hi everyone ,i changed build configuration to release and test app on real device on simulator and not crashing
the problem comes up only when testing on testflight and app crashes right after opening
this is the crash report from test flight:

the full message is:
facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int)::$_0::operator()() const + 56

test on device:
iphone 5s: good
iphone XS max: good
simulator iphone 12: good

test on testflight:
iphone XS max: crashed

any help? thank you

[metehandemir]

@amirhosein5858 i have same issue, did you find any solution?

[amirhosein5858]

@amirhosein5858 i have same issue, did you find any solution?

hi, in build setting / swift copiler - code generation / change optimization level for release to 'No Optimization'
it fix my problem when i try to build with my system but using fastlane and github action for build make app crash as before

[NSShentu]

@amirhosein5858 It's not a good way to solve this issue. if you just close Optimization, you will package much useless codes into your ipa and release to users. And the real bug still hides in codes.