5

I am creating a build using the command 'eas build -p ios' and when launching on testflight it crashes immediately. This is the crashlog testflight gives me. I have added a portion of it below. If more of it is needed let me know.

Update 1: I have added thread 2 considering thats where the crash is coming from.

Update 2: I have also tried using hermes as my js engine.

Update 3: Here are the logs I got from running npx expo start --no-dev --minify: https://easyupload.io/a0q426

Update 4: I found the answer after deconstructing my app and repeatedly submitting builds to testflight. react-native-snap-carousel is the issue. I posted the answer below. I also am including some lines from the crash for keywords on google searches to help others. __exceptionPreprocess + 164 (NSException.m:202) objc_exception_throw + 60 (objc-exception.mm:356)

How can I debug this?

Incident Identifier: D852C7FE-DF24-4B5C-9D9C-E3CCD8E00734
Hardware Model:      iPhone12,1
Process:             AppName [9237]
Path:                /private/var/containers/Bundle/Application/C015CF31-46C4-4B23-BE7F-7B91E29F1DC7/AppName.app/AppName
Identifier:          io.AppNameapp
Version:             1.0.0 (1)
AppStoreTools:       14C17
AppVariant:          1:iPhone12,1:16
Beta:                YES
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           io.AppNameapp [1630]

Date/Time:           2023-01-21 14:33:46.3007 -0500
Launch Time:         2023-01-21 14:33:44.9342 -0500
OS Version:          iPhone OS 16.2 (20C65)
Release Type:        User
Baseband Version:    4.00.00
Report Version:      104

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  2

Last Exception Backtrace:
0   CoreFoundation                  0x1b042de48 __exceptionPreprocess + 164 (NSException.m:202)
1   libobjc.A.dylib                 0x1a97038d8 objc_exception_throw + 60 (objc-exception.mm:356)
2   AppName                             0x104ad7040 RCTFatal + 668 (RCTAssert.m:147)
3   AppName                             0x104b57398 -[RCTExceptionsManager reportFatal:stack:exceptionId:extraDataAsJSON:] + 532 (RCTExceptionsManager.mm:77)
4   AppName                             0x104b57cd8 -[RCTExceptionsManager reportException:] + 1476 (RCTExceptionsManager.mm:147)
5   CoreFoundation                  0x1b04986c4 __invoking___ + 148 (:-1)
6   CoreFoundation                  0x1b0444b2c -[NSInvocation invoke] + 428 (NSForwarding.m:3377)
7   CoreFoundation                  0x1b0444544 -[NSInvocation invokeWithTarget:] + 64 (NSForwarding.m:3474)
8   AppName                             0x104b097e4 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 460 (RCTModuleMethod.mm:584)
9   AppName                             0x104b0bdd0 facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&, int, (anonymous namespace)::SchedulingContext) + 536 (RCTNativeModule.mm:183)
10  AppName                             0x104b0ba04 operator() + 68 (RCTNativeModule.mm:104)
11  AppName                             0x104b0ba04 invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int) + 112 (RCTNativeModule.mm:95)
12  libdispatch.dylib               0x1b7a3f4b4 _dispatch_call_block_and_release + 32 (init.c:1518)
13  libdispatch.dylib               0x1b7a40fdc _dispatch_client_callout + 20 (object.m:560)
14  libdispatch.dylib               0x1b7a48694 _dispatch_lane_serial_drain + 672 (inline_internal.h:2632)
15  libdispatch.dylib               0x1b7a491e0 _dispatch_lane_invoke + 384 (queue.c:3940)
16  libdispatch.dylib               0x1b7a53e10 _dispatch_workloop_worker_thread + 652 (queue.c:6846)
17  libsystem_pthread.dylib         0x1fe4b5df8 _pthread_wqthread + 288 (pthread.c:2618)
18  libsystem_pthread.dylib         0x1fe4b5b98 start_wqthread + 8 (:-1)

...

Thread 2 name:
Thread 2 Crashed:
0   libsystem_kernel.dylib          0x00000001edd9f160 __pthread_kill + 8 (:-1)
1   libsystem_pthread.dylib         0x00000001fe4bc1ac pthread_kill + 268 (pthread.c:1670)
2   libsystem_c.dylib               0x00000001b7aa4c8c abort + 180 (abort.c:118)
3   libc++abi.dylib                 0x00000001fe3fbb8c abort_message + 132 (abort_message.cpp:78)
4   libc++abi.dylib                 0x00000001fe3eba80 demangling_terminate_handler() + 336 (cxa_default_handlers.cpp:71)
5   libobjc.A.dylib                 0x00000001a9709d3c _objc_terminate() + 144 (objc-exception.mm:498)
6   libc++abi.dylib                 0x00000001fe3faf28 std::__terminate(void (*)()) + 20 (cxa_handlers.cpp:59)
7   libc++abi.dylib                 0x00000001fe3faec4 std::terminate() + 56 (cxa_handlers.cpp:88)
8   libdispatch.dylib               0x00000001b7a40ff0 _dispatch_client_callout + 40 (object.m:563)
9   libdispatch.dylib               0x00000001b7a48694 _dispatch_lane_serial_drain + 672 (inline_internal.h:2632)
10  libdispatch.dylib               0x00000001b7a491e0 _dispatch_lane_invoke + 384 (queue.c:3940)
11  libdispatch.dylib               0x00000001b7a53e10 _dispatch_workloop_worker_thread + 652 (queue.c:6846)
12  libsystem_pthread.dylib         0x00000001fe4b5df8 _pthread_wqthread + 288 (pthread.c:2618)
13  libsystem_pthread.dylib         0x00000001fe4b5b98 start_wqthread + 8 (:-1)
MouseWarrior
  • 391
  • 4
  • 19
  • 1
    What version of Expo? We started seeing something similar with SDK 46, but it was resolved with SDK 47. – Slbox Jan 25 '23 at 23:18
  • @Slbox originally was just on SDK 46 and just now upgraded to SDK 47. Given I have only tried one or two builds since. Definitely havent cleared cache or reinstalled node modules since. – MouseWarrior Jan 26 '23 at 02:16
  • 1
    Can you see any errors in the EAS build logs? I don't know if that's barking up the wrong tree, but I'm not sure what else to suggest. – Slbox Jan 26 '23 at 02:21
  • I also created this question but didnt open a bounty on it. It shines some light on the errors I was getting. Thank you for the help though! https://stackoverflow.com/questions/75190275/expo-eas-p-ios-fails-during-fastlane – MouseWarrior Jan 26 '23 at 02:44
  • Does your app also crash on Android? Have you tested that yet? – Slbox Jan 27 '23 at 06:05

2 Answers2

3

The cause of my crash was caused by the library react-native-snap-carousel. After upgrading from 3.9.1 to 4.0.0-beta.6, the crashing stopped.

Before

"react-native-snap-carousel": "3.9.1",

After

"react-native-snap-carousel": "4.0.0-beta.6",
Raptor
  • 53,206
  • 45
  • 230
  • 366
MouseWarrior
  • 391
  • 4
  • 19
2

Copying/expanding on my comment on your other question:

Since you got the app to build but not run, I think your next step would be to try to find a way to access the device logs - or probably easier, try running in development with the flags --no-dev --minify to make the DEV code run more like your PROD code.

The Expo docs encourage using production mode for:

Production mode is most useful for two things:

  • Testing your app's performance, as Development slows your app down considerably.
  • Catching bugs that only show up in production.

I'd also try building Android to see if it also fails - and if so then your issue is much more likely to be something in the JS than any native dependency.

If all else fails, you might be able to find some help on the Expo Discord server.

Slbox
  • 10,957
  • 15
  • 54
  • 106
  • Running in production mode, I get the same crash which is good. Unfortunately expo logs no error so I am using Flipper to grab the crash log. It appears to be a lil different than the crash log I get from testflight so another thing to look at. – MouseWarrior Jan 27 '23 at 14:49
  • It does indeed crash on android as well. Do you think debugging android crashing would be a better route than ios? I do think its a javascript issue. – MouseWarrior Jan 27 '23 at 14:50
  • 1
    I am partial to Android because I understand it a bit better. If you have a physical device, you can connect it to your computer via `adb` and then pull the logs from your device to your computer. [See this answer for details](https://stackoverflow.com/a/9727223). Note though, that just because you can access the logs, doesn't necessarily mean there will be clues. Did you already try `--no-dev --minify`? – Slbox Jan 28 '23 at 20:21
  • 1
    Yes. I am going to add the logs I got with it when it crashed because I think they are actually useful. Again, thank you for the help. Im going to reward you the bounties for all of this. I added the crash logs when using ```--no-dev --minify``` – MouseWarrior Jan 29 '23 at 00:03
  • 1
    I'm just happy to help! Where did you attach the crash logs? I'm so glad you were able to get it to crash that way, because it's so much tougher when it only crashes in production! – Slbox Jan 29 '23 at 00:12
  • 1
    Well I might have spoke too soon... I was able to get it to crash like that and I did have the logs, until my laptop died and I didnt save them. And now of course, it wont crash again xD. I am going to spend the rest of today trying to get it to crash so I can get those logs. If I cannot, ill reward the bounty and move on with life! :)) – MouseWarrior Jan 30 '23 at 20:39
  • 1
    I finally got the crash again. I posted the logs above! I also went ahead and rewarded you the bounty because it expires in 5 hours. Let me know if you see anything interesting in those logs! I am not sure whats up with the imageOffset stuff it mentions. – MouseWarrior Jan 31 '23 at 00:25
  • 1
    Unfortunately still nothing stands out; sorry! You might find someone who knows better on the Discord though - I'm not too keen on the native side of things. Short of that, all I can recommend is slicing down larger and larger pieces of your app until you're left with something that doesn't crash, and then adding them back until you find what crashes - but that's not what anyone wants to hear or do. Sorry I can't be more help! – Slbox Feb 01 '23 at 00:10
  • 1
    All good! I was just about to start deconstructing so now worries. I am curious if you have the answer to this question though. Is removing the call to a component good enough? Or would I need to delete the code from framework in total for it to not crash. In other words, do I have to delete the code to stop the crash or can I just comment out the call to those components? – MouseWarrior Feb 01 '23 at 05:23
  • 1
    That's a great question. Normally commenting out any `import` or `require` of the code and any usages of the imported/required is what you'll need to do - but I can't answer that with 100% certainty regarding how native modules are handled by EAS. When I've done this myself, I just comment out the `import` or `require` and delete the code - if you have to go through a lot of iterations it might help to make a new git branch just to help you track what you're doing - and once you find the issue you can ditch that branch and implement the solution on your main branch. – Slbox Feb 02 '23 at 00:57
  • 1
    Sounds like a nice plan of attack. Thank you so much for all the help! I appreciate it more than you know!!! – MouseWarrior Feb 02 '23 at 03:56
  • 1
    Happy to help; I've been there myself! Let me know if you have any more questions as you progress on that. – Slbox Feb 02 '23 at 03:59