Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

[iOS] Crash immediately on launch on simulators #6842

Closed
LeeroyDing opened this issue Oct 27, 2016 · 7 comments
Closed

[iOS] Crash immediately on launch on simulators #6842

LeeroyDing opened this issue Oct 27, 2016 · 7 comments
Assignees
Labels
build crash iOS Mapbox Maps SDK for iOS release blocker Blocks the next final release
Milestone

Comments

@LeeroyDing
Copy link

Platform: Xcode 7.3 w/ iOS simulator 9.3
Mapbox SDK version: v3.4.0-beta1

Steps to trigger behavior

  1. Create a project and drag the dynamic framework into the project, embed, add strip framework, just usual installation
  2. Drag a view into the storyboard and make the class MGLMapView
  3. Launch on a simulator

Expected behavior

The app launches and shows the map.

Actual behavior

The app crashes.

@boundsj boundsj added iOS Mapbox Maps SDK for iOS crash labels Oct 31, 2016
@boundsj boundsj added this to the ios-v3.4.0 milestone Oct 31, 2016
@boundsj boundsj added the release blocker Blocks the next final release label Oct 31, 2016
@boundsj boundsj self-assigned this Oct 31, 2016
@boundsj boundsj added the build label Oct 31, 2016
@boundsj
Copy link
Contributor

boundsj commented Oct 31, 2016

Thanks for the report @LeeroyDing. I'm able to repro (just embedding the binary causes the crash actually). We've made several changes and fixes for other bugs to the build system in this release so I will need to investigate this more.

@boundsj
Copy link
Contributor

boundsj commented Nov 1, 2016

@LeeroyDing just to confirm something it'd be very helpful if you can provide the stack trace of the crash you are seeing. It seems like the issue may have something to do with the the beta on GH being built with Xcode 8 -- when I build with Xcode 7.3.1 I don't see the issue. I would like to confirm we are seeing the exact same issue with the beta binary though. Thanks!

@boundsj
Copy link
Contributor

boundsj commented Nov 1, 2016

Actually, I can't reproduce the issue when I build locally with Xcode 8 or Xcode 7 so it seems like there may be something wrong with the binary on GH either because of the environment it was built on or because of something that changed in our build scripts recently. In any case, a stack trace would still be helpful @LeeroyDing. Thanks again.

@LeeroyDing
Copy link
Author

I should've mentioned that the stacktrace goes into assembly.

Here's the EXC_BAD_ACCESS point:

dyld_sim`memcmp:
    0x10b5ea2f5 <+0>:  pushq  %rbp
    0x10b5ea2f6 <+1>:  movq   %rsp, %rbp
    0x10b5ea2f9 <+4>:  testq  %rdx, %rdx
    0x10b5ea2fc <+7>:  je     0x10b5ea313               ; <+30>
->  0x10b5ea2fe <+9>:  movzbl (%rdi), %eax
    0x10b5ea301 <+12>: movzbl (%rsi), %ecx
    0x10b5ea304 <+15>: subl   %ecx, %eax
    0x10b5ea306 <+17>: jne    0x10b5ea315               ; <+32>
    0x10b5ea308 <+19>: incq   %rsi
    0x10b5ea30b <+22>: incq   %rdi
    0x10b5ea30e <+25>: decq   %rdx
    0x10b5ea311 <+28>: jne    0x10b5ea2fe               ; <+9>
    0x10b5ea313 <+30>: xorl   %eax, %eax
    0x10b5ea315 <+32>: popq   %rbp
    0x10b5ea316 <+33>: retq   

Here's the stacktrace:

#0  0x000000010b5ea2fe in memcmp ()
#1  0x000000010b5de33b in ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) ()
#2  0x000000010b5e0ee2 in ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) ()
#3  0x000000010b5dd643 in ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) ()
#4  0x000000010b5d1e8d in dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) ()
#5  0x000000010b5d54f1 in dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) ()
#6  0x000000010b5d5280 in dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) ()
#7  0x000000010b5d4c95 in dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) ()
#8  0x000000010b5d474c in dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) ()
#9  0x000000010b5d1c9a in dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) ()
#10 0x000000010b5d1a28 in dyld::load(char const*, dyld::LoadContext const&) ()
#11 0x000000010b5d5623 in dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*) ()
#12 0x000000010b5daee0 in ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) ()
#13 0x000000010b5da458 in ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&) ()
#14 0x000000010b5d2f01 in dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&) ()
#15 0x000000010b5d3f05 in dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) ()
#16 0x000000010b5d0251 in start_sim ()
#17 0x00007fff66a147ac in dyld::useSimulatorDyld(int, macho_header const*, char const*, int, char const**, char const**, char const**, unsigned long*) ()
#18 0x00007fff66a1304f in dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) ()
#19 0x00007fff66a0f276 in dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) ()
#20 0x00007fff66a0f036 in _dyld_start ()

@boundsj
Copy link
Contributor

boundsj commented Nov 1, 2016

Thanks again @LeeroyDing for the report and for sending the trace.

I investigated this and our alpha.5 and beta.1 releases were built with Xcode 8.0 (8A218a). The stripped, dynamic framework output created with this toolchain is not compatible in Swift applications created with prior versions of Xcode (i.e. 7.3.1).

For now, we will need to create the Mapbox iOS SDK releases with Xcode 7.3.1.

If you want to test the current beta in a Swift app using Xcode 7.3.1, you can use the unstripped mapbox-ios-sdk-3.4.0-beta.1-symbols-dynamic.zip available on the GH release page.

@boundsj boundsj closed this as completed Nov 1, 2016
@boundsj
Copy link
Contributor

boundsj commented Nov 2, 2016

@LeeroyDing you should be able to use the stripped dynamic framework in beta 2 release. If you do try it please reopen this if you hit the same issue.

@LeeroyDing
Copy link
Author

Fix confirmed in beta 2. Thanks @boundsj

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
build crash iOS Mapbox Maps SDK for iOS release blocker Blocks the next final release
Projects
None yet
Development

No branches or pull requests

2 participants