google / EarlGrey

:tea: iOS UI Automation Test Framework
http://google.github.io/EarlGrey/
Apache License 2.0
5.61k stars 741 forks source link

Application is not getting launched and getting crashed after updating pods #1155

Open jainhitesh3 opened 4 years ago

jainhitesh3 commented 4 years ago

I had Earlgrey 2.0 working pod setup with my application. But due to some other pod updates (application related) & few other changes I had to do the setup again. Now when I'm trying to do the setup, It is failing to get the automation session for my application (Even for the basic test case). It is getting crashed during the application launch. Here is the backtrace for that crash :

libc++abi.dylib: terminating with uncaught exception of type NSException (lldb) bt thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00000001279092c6 libsystem_kernel.dylib__pthread_kill + 10 frame #1: 0x000000012795cbf1 libsystem_pthread.dylibpthread_kill + 284 frame #2: 0x00000001276cbc45 libsystem_c.dylibabort + 127 frame #3: 0x00000001251125b1 libc++abi.dylibabort_message + 231 frame #4: 0x000000012511274d libc++abi.dylibdefault_terminate_handler() + 265 frame #5: 0x00000001230caa9d libobjc.A.dylib_objc_terminate() + 97 frame #6: 0x000000012511e65e libc++abi.dylibstd::__terminate(void ()()) + 8 frame #7: 0x000000012511e6d3 libc++abi.dylibstd::terminate() + 51 frame #8: 0x00000001230caa22 libobjc.A.dylibobjc_terminate + 9 frame #9: 0x000000012757655f libdispatch.dylib_dispatch_client_callout + 28 frame #10: 0x0000000127577d52 libdispatch.dylib_dispatch_once_callout + 20 frame #11: 0x000000011afed3ac AppFrameworkInitiateCommunicationWithTest + 76 frame #12: 0x000000011afecde9 AppFrameworkInitHostApplication + 9 frame #13: 0x000000011af2a184 dyld_simImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 518 frame #14: 0x000000011af2a382 dyld_simImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40 frame #15: 0x000000011af257b7 dyld_sim`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 343 frame #16: 0x000000011af24974 dyld_simImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 134 frame #17: 0x000000011af24a08 dyld_simImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 74 frame #18: 0x000000011af18342 dyld_simdyld::initializeMainExecutable() + 129 frame #19: 0x000000011af1c497 dyld_simdyld::_main(macho_header const*, unsigned long, int, char const, char const, char const, unsigned long) + 4395 frame #20: 0x000000011af17624 dyld_simstart_sim + 136 frame #21: 0x0000000125357234 dylddyld::useSimulatorDyld(int, macho_header const, char const*, int, char const, char const, char const*, unsigned long, unsigned long) + 2238 frame #22: 0x00000001253550ce dyld`dyld::_main(macho_header const, unsigned long, int, char const, char const, char const, unsigned long) + 522 frame #23: 0x0000000125350503 dyld`dyldbootstrap::start(macho_header const, int, char const*, long, macho_header const, unsigned long*) + 1167 frame #24: 0x0000000125350036 dyld_dyld_start + 54 (lldb)

It seems like this has something to do with 'AppFramework'. I'm not exactly sure though. Note: This exact setup was working before but now it's giving this issue.

I tried recreating this issue with the Earlgrey sample application and I'm able to recreate it.

This is the podfile I'm using for my project.

I have tried this with Xcode Version: 11.3 (App Store version), Xcode Version: 11.2.1 & Xcode version: 11.1

jainhitesh3 commented 4 years ago

FYI: Even with the basic podfile setup (EarlGreyExample project), I'm not able to run the project. Steps: 1: Downloaded project from the source EarlGreyExample 2: Did 'pod install' 3: Ran tests (It crashed at the same stack trace again).

Xcode versions: 11.2.1 & 11.3

Note: No changes were made to podfile here.

jainhitesh3 commented 4 years ago

As suggested by Brett Fazio, Since the culprit is eDO's latest version-0.9.1

You can pin eDO to 0.9.0 even though eDO is a dependency by putting pod ‘eDistantObject’, ‘0.9.0’ directly under everywhere you see pod ‘EarlGreyTest’

After applying this workaround, I'm able to run the application and tests under it.

brettfazio commented 4 years ago

Additionally when the new version of EarlGrey is released (the one designed to work for eDO 0.9.1) the problem should resolve itself. Pinning to 0.9.0 is perfectly valid for now though.