Crash on Initialization

bugsnag / bugsnag-cocoa-performance

Monitor the start-up, screen loading and network requests of your iOS app and see the results in your BugSnag dashboard.

https://docs.bugsnag.com/performance/integration-guides/ios

MIT License

11 stars 8 forks source link

Crash on Initialization #276

Closed nchegireddy closed 2 weeks ago

nchegireddy commented 3 weeks ago

Describe the bug

Bugsnag Performance crashes on initialization.

Edit 1: We were able to fix the crash by setting networkRequestCallback in the config to { _ in return .init() } which I'm not sure if it's the right approach.

Edit 2: We are using the SDK initialization and not the plist initialization.

Environment

BugSnag Performance library version: 1.6.0
BugSnag Error Monitoring library version (if any): 6.29.0
CocoaPods version:
iOS/tvOS/macOS version(s): iOS
Simulator or physical device: Simulator
Xcode version: 15.4
Swift version (if applicable): 5.9

clr182 commented 3 weeks ago

Hi @nchegireddy

Thank you for raising this with us. We are currently working on a patch for this issue. Our current aim is to have a release out early next week. We'll be sure to keep you informed via this thread once the patch is released.

For background, The issue exists for users who call the reportNetworkRequestSpan API to report their own network spans but who don't set a callback. This crept in during a recent enhancement and unfortunately was a combination that wasn't in our end-to-end tests. You can set a no-op callback to avoid the issue until we get the patch release out.

eseay commented 3 weeks ago

Hi @nchegireddy

Thank you for raising this with us. We are currently working on a patch for this issue. Our current aim is to have a release out early next week. We'll be sure to keep you informed via this thread once the patch is released.

For background, The issue exists for users who call the reportNetworkRequestSpan API to report their own network spans but who don't set a callback. This crept in during a recent enhancement and unfortunately was a combination that wasn't in our end-to-end tests. You can set a no-op callback to avoid the issue until we get the patch release out.

@clr182 Great to know that a fix is already in the works! We landed on the same workaround of setting the no-op callback, as you mentioned. We'll keep an eye out for the patch and get that integrated as soon as it's ready.

nchegireddy commented 2 weeks ago

I get no crashes on 1.6.1, so closing this issue.