react-native: Random Native iOs error : "Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Could not locate shadow view with tag #8'"

Hi there,

I have regularly a really weird and random error in Xcode when running on the simulator, on iOs only :

I had this bug since RN v0.21 and still have it on RN v0.26. It’s really hard to reproduce, but I think it has to do with the asyncStorage somehow because commenting my code (it seems especially AsyncStorage.multiGet) interacting with the asyncStorage, relaunching the app and uncommenting then reloading the JS package makes the bug go away…

The stack trace in Xcode is :

2016-06-07 10:07:56.514 RNOSDStarter[33977:6342335] Communications error: <OS_xpc_error: <error: 0x106ff7b40> { count = 1, contents =
    "XPCErrorDescription" => <string: 0x106ff7ef0> { length = 22, contents = "Connection interrupted" }
}>
2016-06-07 10:11:39.995 MyProject[33977:6335407] *** Assertion failure in __33-[RCTUIManager setFrame:forView:]_block_invoke(), /Users/adrien/Projects/myProject/node_modules/react-native/React/Modules/RCTUIManager.m:398
2016-06-07 10:11:40.037 MyProject[33977:6335407] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Could not locate shadow view with tag #8'
*** First throw call stack:
(
    0   CoreFoundation                      0x000000010382ad85 __exceptionPreprocess + 165
    1   libobjc.A.dylib                     0x00000001029f6deb objc_exception_throw + 48
    2   CoreFoundation                      0x000000010382abea +[NSException raise:format:arguments:] + 106
    3   Foundation                          0x0000000102640e1e -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 169
    4   RNOSDStarter                        0x000000010226b342 __33-[RCTUIManager setFrame:forView:]_block_invoke + 386
    5   libdispatch.dylib                   0x0000000106cb7d9d _dispatch_call_block_and_release + 12
    6   libdispatch.dylib                   0x0000000106cd83eb _dispatch_client_callout + 8
    7   libdispatch.dylib                   0x0000000106cbe82c _dispatch_queue_drain + 2215
    8   libdispatch.dylib                   0x0000000106cbdd4d _dispatch_queue_invoke + 601
    9   libdispatch.dylib                   0x0000000106cc0996 _dispatch_root_queue_drain + 1420
    10  libdispatch.dylib                   0x0000000106cc0405 _dispatch_worker_thread3 + 111
    11  libsystem_pthread.dylib             0x00000001070154de _pthread_wqthread + 1129
    12  libsystem_pthread.dylib             0x0000000107013341 start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb) 

Any help or lead on how to debug this would be awesome!

Other info :

  • Using Mac OSX El Capitan 10.11.5
  • We are using redux and are interacting with AsyncStorage in a middleware
  • AsyncStorage is called directly after reloading the package (first thing we do once the app is launched : Get data stored in asyncStorage).

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 19
  • Comments: 15 (4 by maintainers)

Most upvoted comments

In my cases, it seems that while fetching from AsyncStorage if view appear and disappear too quickly this error seems occurs. If I do below it works fine for me.

setTimeout(() => {
  store.dispatch(toggleLoading(false));
}, 500);
return;

Event I postpone dispatch using setTimeout, 0 magic doesn’t help. So weird, but it is working for me. I tried this because error indicates something about views, not storage. Could not locate shadow view with tag

@adrienthiery i had the same problem calling AsyncStorage.getItem in a componentDidMount method, and what was causing the problem had to do with setting the state of the component on the callback of AsyncStorage.getItem, i guess the scope was not set at that point in order to call this.setState({myProp: true}); . But just so you know this only happens on “debug” build type on the device, it will NOT happen on Simulator and it will NOT happen on “release” type build because for release assertions are canceled so kinda makes sense. Here is a snapshot on how my code looked like when it failed, removing this.setState(…) solved it. I wasn’t needing it anyway. https://www.dropbox.com/s/46m8l4v6vzcqk7d/Screenshot 2016-06-10 22.29.58.png?dl=0

I’m having this issue. It has nothing to do with the code. Don’t change your code. My fellas in the company doesn’t have any problem with the same xcode, simulator and macos version. Sourcecode is also the very same.

I’d say it’s a problem of Apple.

For me this was about presenting and hiding a view too quickly