React-native: Freeze & Crash when remote debug enabled [email protected]

[patrikholcak]

Description

I tried to update an existing project to [email protected] and noticed that the app freezes and crashes when I try to dispatch a redux action open a modal. I then went and tried to isolate the issue and found out it crashes only when remote debug is enabled, which makes me think it might not be related to redux. This is the last error in console:

Error: Attempted to remove more RCTKeyboardObserver listeners than added

Reproduction

1. clone and install patrikholcak/react-native-remote-bug
2. Run iOS simulator, toggle remote debug on
3. Click Toggle modal — first click will freeze the app and the second one will crash it

Solution

No idea.

Additional Information

• React Native version: 0.42.0-rc.1
• Platform: iOS
• Operating System: MacOS

[neosavvy]

I just started a small Application to learn some React Native / Redux / React Navigator and noticed that if I kill my application on device and then try to open it again, it'll crash after a long timeout.

I have a project here with similar errors after installing it on device, works fine in simulator.

https://github.com/neosavvy/lift

[reyesr]

I think this issue is also related to #12368 and appears when using Modal on IOS, in a specific context, in debug mode.

I do not use redux, my app actually uses NavigationExperimental (the root component of the display is a NavigationCardStack) and when I display a Modal on IOS in Debug Mode, the render() function freezes and the modal is never displayed. On Android, the very same code works fine in both Normal and Debug Mode.

This freeze happens in 0.42.0-rc3, but NOT in 0.41.2.

I couldn't create a minimal app that reproduces the bug, as just adding a modal to the default app created after an init' does not trigger the issue. There is something more, but not sure what makes the issue appear.

[K-Leon]

For me it's triggered if i'm transitioning towards a scene that contains an visible modal which is shown on render.

[K-Leon]

The only significant change i observed between .41 and .42 is this one: https://github.com/facebook/react-native/commit/f33f84e75f1957f381e34bc99a902b9c324db6fa

Could this be related?
@shergin

[shergin]

@K-Leon It is very unlikely, IMO. Could you please locally revert that (f33f84e) commit and test again?

[K-Leon]

@shergin Sorry for the wrong ping! You're absolutely right.

i did a git bisect of the whole release and the offending commit is https://github.com/facebook/react-native/commit/407973ab27212616cdfac4509875beb6d20c1222
@cailenmusselman Could you look into it? To resolve this i deleted the elevation part locally and it works perfectly again.
Is there some polyfill missing in chrome debugger to support elevation props?

Funny thing is I noticed a similar bad behavior on android - i'm still looking into it where it could come from. It's not related to a modal but seems to be related to touchables on top of a native view - but it also only happens while debugging.

[cailenmusselman]

Hey guys, I'll take a look at this early this week.

Weird that it would be my commit causing an issue on iOS though since the only edit was to the YellowBox's "elevation" style property, which is an android-only property.

[neosavvy]

I found that it was a packaging thing, but it just doesn't give a helpful
error when it crashes - it just hangs until it crashes.

I believe when doing a debug app, if you get off wifi, the JS assets aren't
available for your app so it just crashes on the splash screen.

I packaged as a non-debug app and it pushed all the code contents to my
phone and worked fine when I was off wifi - I believe this may be by
design. The debug version could just warn you as a "new dev" that you need
to be connected to wifi for Debug to work (if that's the case). I was just
clueless as to what was going on or where to look. Wasted an embarrassing
amount of time trying to figure it out.

On Mon, Feb 27, 2017 at 10:33 AM, cailenmusselman [e-mail]
wrote:

Hey guys, I'll take a look at this early this week.

Weird that it would be my commit causing an issue on iOS though since the
only edit was to the YellowBox's "elevation" style property, which is an
android-only property.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/12223#issuecomment-282753556,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJhxQVgOoNOZp9mSwzisMd-jzkvrd7Lks5rguzIgaJpZM4L3tpC
.

--

Adam Parrish | 349 5th Avenue, Suite 412 | New York, NY, 10016 |
919.741.9597

[K-Leon]

@neosavvy >
This has absolutely nothing (!) to do with wifi or dropping connections - i've a stable environment and it's also reproducable on Simulator every time....

The Elevation thing seems to be incompatible with chrome js engine or triggers there some bug.

[cailenmusselman]

Okay @K-Leon I'll still take a look early this week. Are your steps to reproduce different from the original (patrikholcak/react-native-remote-bug)?

[neosavvy]

Wow @Leon - my bad just must have misread something. (!)

On Mon, Feb 27, 2017 at 12:13 PM, cailenmusselman [e-mail]
wrote:

Okay @K-Leon https://github.com/K-Leon I'll still take a look early
this week. Are your steps to reproduce different from the original
(patrikholcak/react-native-remote-bug)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/12223#issuecomment-282785005,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJhxXBz14FkCCb4EDk2RVX-twvQerhuks5rgwRAgaJpZM4L3tpC
.

--

Adam Parrish | 349 5th Avenue, Suite 412 | New York, NY, 10016 |
919.741.9597

[K-Leon]

No - not really. Happens all the time for me. Just take simulator, iOS and a medium sized app. Pushing a button that leads to a scene with a modal triggers it for me.

[alphasp]

I am having similar issue when running on ios with version 0.43.0-rc.0 with remote debug enabled.
It can be reproduce by creating a new project with react-native init --version="0.43.0-rc.0" rn43, then add a console.warn in render function, the screen will be render in blank and no yellow box appear.

  render() {
    console.warn("test warning here");
    return (
      <View style={styles.container}>
        <Text style={styles.welcome}>
          Welcome to React Native!
        </Text>
        <Text style={styles.instructions}>
          To get started, edit index.ios.js
        </Text>
        <Text style={styles.instructions}>
          Press Cmd+R to reload,{'\n'}
          Cmd+D or shake for dev menu
        </Text>
      </View>
    );
  }

[cailenmusselman]

Will try and find the time to investigate today

[micopc]

I'm also having the same problem on version 0.42. When I try to open a modal, the app freezes and after trying to interact with it, it crashes. Also the remote debugger is showing this warning: "Calling of [-RCTUIManager setFrame:forView:] which is deprecated." Which might be related to the commit f33f84e75f1957f381e34bc99a902b9c324db6fa

[cailenmusselman]

Oooookay guys, so I have it figured out... sort of.

The elevation changes I introduced to YellowBox cause iOS apps to hang when remote debugging is enabled and a warning is logged.

So my changes do not effect the Modal component directly, it's just that Modal is logging the warning "Calling of '[-RCTUIManager setFrame:forView]' which is deprecated" which in turn brings out the bug introduced by my YellowBox changes in iOS.

So the actual bug we're observing is what @alphasp posted.

In summary:
Android + no remote debugging = OK
Android + remote debugging = OK
iOS + no remote debugging = OK
iOS + remote debugging = HANGS

Interestingly, if I change elevation: Number.MAX_VALUE to Number.MAX_SAFE_INTEGER the bug dissappears. So maybe there's some sort of overflow occurring on iOS, I'm not sure.

I don't really have the time to get to the actual root of the issue, so I just propose any of these changes:

1)

elevation: Platform.OS === 'android' ? Number.MAX_SAFE_INTEGER : undefined // since elevation IS only an android property

or 2)

elevation: Number.MAX_SAFE_INTEGER

or 3)

elevation: 1000 // pick a value, any value

Preferences? Or does someone want to get to the ACTUAL root of the issue?

[reyesr]

Thansk for digging into the issue @cailenmusselman !

I think your first choice (1) is pretty good, as long as elevation is not supported on IOS, keeping it undefined seems the better choice (ie, with the minimal possible side-effects)

[hilkeheremans]

@cailenmusselman EXCELLENT work! I would also go with option (1).

Perhaps very obvious, but probably a good idea to comment a little extra in the code to provide context on why this change was done.

[mkonicek]

Thanks for the fix @cailenmusselman! https://github.com/facebook/react-native/pull/12744

Once it lands in master I'll cherry-pick it to 0.42 and 0.43.

[robcalcroft]

Is there a work around for this yet?

[rcugut]

@robcalcroft the way I solved it was to locally edit the YellowBox.js file (inside node_modules/react-native/...) with the 3 lines from this commit: https://github.com/facebook/react-native/commit/adeb5ff940cb56a594b1f653660f22faeeebf382

Since this is only breaking development, it has no side-effects for production. It's an interim solution until a new react-native release is baked

[alphasp]

@robcalcroft the fix is already available in v0.42.1 and v0.43.0-rc.2

[adrai]

v0.42.1 seems not to be published right now, but you can test it by putting this instead of v0.42.1 in the package.json: facebook/react-native#v0.42.1

[anonrig]

PS: When will the v.42.1 be released?

[robcalcroft]

@alphasp ok thanks

[adrai]

I've tested with facebook/react-native#v0.42.1 in the package.json...

for ios everything fine (just a new warning) but for android the build fails with something like:

.../node_modules/react-native-image-crop-picker/android/src/main/java/com/reactnative/ivpusic/imagepicker/PickerModule.java:31: error: cannot find symbol
import com.facebook.react.modules.core.PermissionAwareActivity;
                                      ^
  symbol:   class PermissionAwareActivity
  location: package com.facebook.react.modules.core

:-(

[adrai]

But seems to work better with: v0.43.0-rc.2 and new react v16.0.0-alpha.3 (on ios and android)

[just4fun]

I upgraded to v0.42.2 and it works.

[sundou]

I set console.disableYellowBox = true;
and it works too.

[amanthegreatone]

Hi,
Having same issue with RN 0.44.2. Launch the app and in debug mode and it freezes.

[cwagner22]

My app is also crashing when Remote Debugging is enabled, using 0.44.2. (It happens randomly so hard to track down, like every 1-5 mins). And with this issue happening at each launch it makes RN development a nightmare for me.

[soundstage]

I am having this issue on RN 0.45. Will upgrading to RN 0.46 or 0.47 solve this issue?

[rod-stuchi]

Nope, fresh install RN 0.47.2 still has the problem. I tested only on Android.

edit

I has testing on AVD with API 23, with Remote JS Debugging enabled app crash when reload is called.

In logcat

E/Surface: getSlotFromBufferLocked: unknown buffer: 0xf40bd5c0
...
Fatal signal 11 (SIGSEGV), code 1, fault addr 0xea0c6000 in tid 3664

On AVD with API 26, works nicely :smile:

[dobiedad]

I had this issue today, tried all solutions but nothing worked. In the end i just rm -rf ios/build which seemed to have done the trick.

[sospedra]

@sundou workaround worked for me

Place this at your app's entry point

console.disableYellowBox = true

Tho... Well, this should be fixed 😞

[Fr33maan]

YellowBox didn't did the trick here but switching to API 26 works ! Thanks @rod-stuchi

[Nevosis]

Switching to 26 worked for me too, thanks a lot. But it shouldn't be right ?

[avishayil]

Running the project from XCode, rather than run-ios, solves the issue here.
Still persists when running with run-ios.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.