Expo Go with React-Redux crashes on published app but works in local

I’m still trying to find out what may have caused the issue. I know I did an expo doctor, updated my expo go (So I can be on SDK 47), and installed redux recently. They may seem innocuous so I don’t think these should be a problem.

Anyway the behaviour I saw was that everything is fine when using the server on my local machine but when I did an expo publish and try to run it it crashes at start up.

I tried --no-dev on the local server, it has no issues.

The logs I see on console showed a number of entries like this

Synchronous remote object proxy returned error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.commcenter.coretelephony.xpc was invalidated: failed at lookup with error 3 - No such process." UserInfo={NSDebugDescription=The connection to service named com.apple.commcenter.coretelephony.xpc was invalidated: failed at lookup with error 3 - No such process.}

Finally ending in.

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[EXReactAppExceptionHandler handleSoftJSExceptionWithMessage:stack:exceptionId:extraDataAsJSON:]: unrecognized selector sent to instance 0x600000edbaf0'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007ff8004278cb __exceptionPreprocess + 242
	1   libobjc.A.dylib                     0x00007ff80004dba3 objc_exception_throw + 48
	2   CoreFoundation                      0x00007ff800436ad8 +[NSObject(NSObject) instanceMethodSignatureForSelector:] + 0
	3   CoreFoundation                      0x00007ff80042bb28 ___forwarding___ + 814
	4   CoreFoundation                      0x00007ff80042e088 _CF_forwarding_prep_0 + 120
	5   Expo Go                             0x000000010a866e41 -[ABI47_0_0RCTExceptionsManager reportSoft:stack:exceptionId:extraDataAsJSON:] + 264
	6   Expo Go                             0x000000010a867998 -[ABI47_0_0RCTExceptionsManager reportException:] + 1663
	7   CoreFoundati<…>

Tested with a fresh blank typescript app and expo publish has no issues.
Re-applying the dependencies only no issues


A similar scenario was posted though the answer doesn’t allow me to do much as I pretty much have a barebones babel.config.js already.

Also React native project crashing with Redux Toolkit - Stack Overflow

So reverting the code to not use React redux got it to function again, not sure why I need to go that far.

Putting in the redux code for the store and a basic reducer causes it to crash.

I’ve actually reduced the crashing code to simply

import { configureStore } from "@reduxjs/toolkit";
export const store = configureStore({
  reducer: {},
});

However, when I do the same for a fresh project it doesn’t crash. So I am not sure at which junction does my app add something that would cause the crash.

dug a bit further and found that this check it performs seems to be causing the cash.

/*
 * This is a dummy function to check if the function name has been altered by minification.
 * If the function has been minified and NODE_ENV !== 'production', warn the user.
 */

function isCrushed() {}

if (process.env.NODE_ENV !== 'production' && typeof isCrushed.name === 'string' && isCrushed.name !== 'isCrushed') {
  warning('You are currently using minified code outside of NODE_ENV === "production". ' + 'This means that you are running a slower development build of Redux. ' + 'You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify ' + 'or setting mode to production in webpack (https://webpack.js.org/concepts/mode/) ' + 'to ensure you have the correct code for your production build.');
}

This looks like it might be the following issue:

(The segfault part, not the Constants.manifest part)

See also:

EDIT:

If it’s not the above issue, did you try --minify (by itself, or in addition to --no-dev)?

1 Like

Now it crahses on expo go with local server once --minify and --no-dev are both enabled.

It does not crash with just --minify but you get (as I would expect)

WARN Got a component with the name ‘s’ for the screen ‘Modal’. React Components must start with an uppercase letter. If you’re passing a regular function and not a component, pass it as children to ‘Screen’ instead. Otherwise capitalize your component’s name.
@http://192.168.0.11:19000/src/init/index.ts.bundle?platform=ios&dev=true&hot=false&minify=true:1543:1687

since it’s minified.

Unfortunately it hasn’t shown why it does it. But it is likely to do with the prod vs non-prod logic of redux toolkit. Going to try a different approach where I just do redux only.

At the very least --no-dev and --minify reduces the amount of churn I have to do with expo publish.

Here’s the crashlog its SIGABRT
Incident Identifier: 79651CD9-AAC6-4CB1-86FD-DFD8F05399F7CrashReporter Key: - Pastebin.com

The portion that failed is

Thread 9 name:   Dispatch queue: com.facebook.ABI47_0_0React.ExceptionsManagerQueue
Thread 9 Crashed:
0   libsystem_kernel.dylib        	       0x1cd6e6200 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x1dda891ac pthread_kill + 268
2   libsystem_c.dylib             	       0x198a313e4 __abort + 128
3   libsystem_c.dylib             	       0x1989d9c98 abort + 192
4   libc++abi.dylib               	       0x1dd9c9b8c abort_message + 132
5   libc++abi.dylib               	       0x1dd9b9a80 demangling_terminate_handler() + 336
6   libobjc.A.dylib               	       0x18a759d3c _objc_terminate() + 144
7   libc++abi.dylib               	       0x1dd9c8f28 std::__terminate(void (*)()) + 20
8   libc++abi.dylib               	       0x1dd9c8ec4 std::terminate() + 56
9   libdispatch.dylib             	       0x198975ff0 _dispatch_client_callout + 40
10  libdispatch.dylib             	       0x19897d694 _dispatch_lane_serial_drain + 672
11  libdispatch.dylib             	       0x19897e1e0 _dispatch_lane_invoke + 384
12  libdispatch.dylib             	       0x198988e10 _dispatch_workloop_worker_thread + 652
13  libsystem_pthread.dylib       	       0x1dda82df8 _pthread_wqthread + 288
14  libsystem_pthread.dylib       	       0x1dda82b98 start_wqthread + 8

OK, it looks like the immediate cause is either an assert() or more likely an unhandled Objective C exception. I’m no Objective C expert, so I could be wrong, but that’s what it seems like to me.

I haven’t tried the Expo updates crash on iOS, so not sure how it manifests there. On Android it results in a segmentation fault. But it still seems to me like if it results in a native crash on Android there’s a chance it will also result in a native crash on iOS.

What happens if you wrap the dummy function check in a try/catch? I suppose you’ll need to patch it with patch-package.

If I do (sorry recalling from memory)

try {
  const {configureStore} = require("@reduxjs/toolkit");
  console.log(configureStore);
} catch (e) {
  Alert.alert("error");
}

The app crashes.

If I do

try {
  const {createStore} = require("redux");
  console.log(configureStore);
} catch (e) {
  Alert.alert("error");
}

It also crashes unless I patch the package to remove the function isCrushed() {}.... logic

I tried

try {

function isCrushed() {}

if (process.env.NODE_ENV !== 'production' && typeof isCrushed.name === 'string' && isCrushed.name !== 'isCrushed') {

warning('You are currently using minified code outside of NODE_ENV === "production". ' + 'This means that you are running a slower development build of Redux. ' + 'You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify ' + 'or setting mode to production in webpack (https://webpack.js.org/concepts/mode/) ' + 'to ensure you have the correct code for your production build.');

}

} catch (e) {

console.error("error " + e);

}

no error just crash

Weird

my thoughts exactly :stuck_out_tongue:

Fwiw, I did try throwing an uncaught exception, generating an update and then Previewing that update in Expo Go on iOS and it did crash (no red box error). I haven’t checked the device logs yet to see what they say about the crash.

Whether that’s in any way related to your problems, I have no idea.

1 Like

Are you using combineReducers from redux before passing the reducers to configureStore?

I was doing it with SDK 47 and Expo Go kept crashing and my JS thread was freezing, only in my production build though (When running npx expo start --no-dev --minify). Once I removed the combineReducers and passed a plain object to configureStore it started to work again! :slight_smile:

Maybe at one point but now I’ve reduced it to just either the configureStore or createStore call only with a single reducer on one of the earlier posts.

I just changed to jsEngine: "hermes" still no luck crashes with just

import '@reduxjs/toolkit';

I had the exact same issue. Expo crashed with just the import '@reduxjs/toolkit' and only in --no-dev --minify mode. --no-dev as well as --minify modes worked, when used as standalone extension.

Also, the app crashed with no specific redux logic. It was enough to crash with just the single import @reduxjs/toolkit

I got it at least back running by perfoming expo-cli doctor with the suggested fixes and a complete removal of both my node_modules and yarn.lock files and then reinstalling package.json dependencies.

1 Like

The PR is here but it’s not merged yet. And the associated bug

Thanks for the PR. I’m thinking of using Redux and RTK for my new project, this means that I will not be able to publish my app until the PR has been accepted and a new release is made ? Or is there any way to circumvent this issue in production such as not minifying the code ?

You can probably patch it using patch-package