Hey @hingarn, apologies for this. We're looking into the issue but for now please downgrade to 7.4.0.

Hey @hingarn - I wasn't able to reproduce this. I was wondering if you could tell me a little more about your setup, in particular:

• When do you call the Vision API that crashes Crashlytics? (eg. right at startup, after a button click?)
• Do you call dlopen in your codebase?
• Are you able to reproduce this on a device?

Any other information that's specific to your environment would be hugely appreciated.

Hey @samedson, here is the info.

• I call Vision API when there is an image in the viewport, so after the app is fully loaded and the initial UI is rendered. If there are no images initially, the app doesn't crash. Then, once I scroll in an image, it crashes
• I do not call dlopen. The call is present in Facebook SDK in the app, but it is not executed
• It does not crash on a device

Our environment is straightforward. We do not do any custom setup. We do use Shake SDK for bug reporting, which does method swizzling.

Please let me know if I can provide you any additional details about the setup.

The same happens since 7.5.0 on my M1 machine, also only in simulator. Using Xcode Version 12.4 (12D4e)

If it helps, I am seeing the same issue but am not using the Vision framework in my app. I'm using Core Image. I'm getting this crash upon initializing a CIContext.

My reproduction case still isn't crashing on an M1 machine, so here's the quickstart project that I'm using to try and reproduce the issue with calls to the Vision API. Would someone here be able to try out this project and see if it reproduces the behavior on their machine, or tweak it such that it does?

Xcode Project Quickstart using the Vision API

It seems like common factors are:

• Xcode 12.4
• Simulator on Apple Silicon Mac

I am seeing this issue on a non-Apple Silicon Mac, in the simulator. I’ll give that sample project a try and see if I can reproduce it.

@samedson created a PR that reproduces the issue for me: samedson/issues#1

I am seeing this issue as well. The machine is an iMac Pro (10.15.7), running my iOS app in the Simulator (Xcode 12.2). We are using version 7.5.0 of the SDK. The crash happens on startup of the application:

I should be clear the only framework we're using in our application is Crashlytics (and any dependencies it may be using.)

Thank you @chrisvasselli for the repro case 👍 and everyone for the info. Somehow it still doesn't crash for me, but I believe we know what the bug is. Going to update to the newest macOS to see if that's the issue because I believe everything else with my environment matches reports here. It's likely a race condition based on the code.

We're going to post a change later today that should fix this issue, while still keeping the startup performance zippy (which was the initial reason for the change in 7.5.0 that caused this bug).

Could folks try out the change once it comes out?

Hi all - here's the PR for the proposed fix:
#7459

Update: we've pushed a change to the main branch. Please let us know if this helps!

I've updated to the latest version and don't see the crash anymore.

Great, I'm going to close this for now but feel free to reopen if this didn't resolve the problem.

I'm seeing something very similar. I'm running Xcode 12.4, Firebase SDK 7.5, using Cocoapods and computer is a MacBook Air i5. The crash happens on startup.

It takes place here in FIRCLSBinaryImage.m...

if (FIRCLSMachOSliceIs64Bit(slice)) {
    const struct section_64* sect =
        getsectbynamefromheader_64(slice->startAddress, segName, sectionName);
    if (!sect) {
      return false;
    }
    section->addr = sect->addr;
    section->size = sect->size;
    section->offset = sect->offset;
  } else {
    // crash on next line (Thread 9: EXC_BAD_ACCESS (code=1, address=0x1f57a1887))
    const struct section* sect = getsectbynamefromheader(slice->startAddress, segName, sectionName);
    if (!sect) {
      return false;
    }
    section->addr = sect->addr;
    section->size = sect->size;
    section->offset = sect->offset;
  }

Using the PR fixes the problem for me too