Expected behavior

Forcing the app to crash by calling fatalError("i am a message") includes the "i am a message" text in the bugsnag report.

Observed behavior

No message is included: https://app.bugsnag.com/recharge-labs/ios-consumer/errors/5bbe93a371c2fc001a3e9ba8

Version

Bugsnag 5.17.0 Xcode Version 10.0 (10A255)

Additional information

Original feature request (#159) and PR to add the feature (#188). I'm guessing that something in Swift 4.2 or Xcode 10 changed the way those notable addresses are attached to the crash report? Or maybe broke the heuristics in some other way?

Expected behavior

different stacktraces are grouped into different errors

Observed behavior

Two totally different stacktraces are grouped into the same error: https://app.bugsnag.com/recharge-labs/ios/errors/5a0226b08110ee00185760ea?&event_id=5a5681dde2a9ff00189926dc https://app.bugsnag.com/recharge-labs/ios/errors/5a0226b08110ee00185760ea?&event_id=5a541f0ed0f0c0001cf4853b

Version

5.14.0

Description

Bugsnag won't install using XCode 11 + Carthage

Environment

Library versions:

• Bugsnag version (from your Podfile, Podfile.lock, or elsewhere): 5.22.7
• Carthage version (if any): 0.33
• iOS/tvOS/macOS version(s): MacOSX 10.15 Catalina

Example code snippet

carthage update bugsnag-cocoa --no-use-binaries --cache-builds --platform iOS

Result

(1 failure)
Build Failed
	Task failed with exit code 65:
	/usr/bin/xcrun xcodebuild -workspace /Users/marcelosalloum/Workspace/persona-ios/Carthage/Checkouts/bugsnag-cocoa/OSX.xcworkspace -scheme Bugsnag -configuration Release -derivedDataPath /Users/marcelosalloum/Library/Caches/org.carthage.CarthageKit/DerivedData/11.0_11A420a/bugsnag-cocoa/v5.22.7 -sdk iphoneos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/g_/x9df0hls2k51twkgxtx68k9w0000gn/T/bugsnag-cocoa SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in /Users/marcelosalloum/Workspace/persona-ios/Carthage/Checkouts/bugsnag-cocoa)

This usually indicates that project itself failed to compile.

Describe the bug

We're seeing a crash of unknown cause coming from Bugsnag. This has impacted 7 customers a total of 7 times, so it's fairly rare.

Steps to reproduce

Unknown

Environment

• Bugsnag version: 6.1.3
• CocoaPods version: 1.9.3
• Carthage version (if any): n/a
• iOS/tvOS/macOS version(s): 13.7.0, 14.0.1
• Simulator or physical device: iPhone 11
• XCode version: 11.2.1
• Swift version (if applicable): 5.1

Stack Trace

Crashed: MyQueue
0  libobjc.A.dylib                0x186892b30 objc_msgSend + 16
1  Foundation                     0x186e9a3b8 -[NSArray(NSKeyValueCoding) valueForKey:] + 376
2  Foundation                     0x186ea57f8 -[NSArray(NSKeyValueCoding) valueForKeyPath:] + 428
3  MyApp                           0x1012790ac -[BugsnagEvent serializeBreadcrumbs] + 630 (BugsnagEvent.m:630)
4  MyApp                           0x101279a04 -[BugsnagEvent toJson] + 756 (BugsnagEvent.m:756)
5  MyApp                           0x10126d180 -[BugsnagClient notifyInternal:block:] + 1046 (BugsnagClient.m:1046)
6  MyApp                           0x10126cf78 -[BugsnagClient notify:handledState:block:] + 1011 (BugsnagClient.m:1011)
7  MyApp                           0x10126c1a0 -[BugsnagClient notifyError:block:] + 882 (BugsnagClient.m:882)
8  MyApp                           0x10126463c +[Bugsnag notifyError:block:] + 136 (Bugsnag.m:136)
9  MyApp                           0x101d28a68 specialized BugsnagLogStoreWriter.write(level:message:parameters:) + 4395485800 (<compiler-generated>:4395485800)
10 MyApp                           0x101d1b6b8 AggregateLogStoreWriter.write(level:message:parameters:) + 4395431608 (<compiler-generated>:4395431608)
11 MyApp                           0x101d1b778 protocol witness for LogStoreWriter.write(level:message:parameters:) in conformance AggregateLogStoreWriter + 4395431800 (<compiler-generated>:4395431800)
12 MyApp                           0x101d21e30 Logger.log(level:_:parameters:) + 4395458096 (<compiler-generated>:4395458096)
13 MyApp                           0x101bf9974 closure #1 in RedactedType1.redactedMethod + 4394244468 (<compiler-generated>:4394244468)
14 MyApp                           0x101ef5e50 RedactedType3.redactedMethod + 318 (RedactedType3.swift:318)
15 MyApp                           0x100cf3f98 protocol witness for RedactedType2.redactedMethod in conformance RedactedType3 + 4378492824 (<compiler-generated>:4378492824)
16 MyApp                           0x101bf8e30 closure #1 in closure #1 in RedactedType1.redactedMethod + 305 (RedactedType1.swift:305)
17 MyApp                           0x100ba5898 thunk for @escaping @callee_guaranteed () -> () + 4377122968 (<compiler-generated>:4377122968)
18 libdispatch.dylib              0x1868399a8 _dispatch_call_block_and_release + 24
19 libdispatch.dylib              0x18683a524 _dispatch_client_callout + 16
20 libdispatch.dylib              0x1867e68a4 _dispatch_lane_serial_drain$VARIANT$mp + 608
21 libdispatch.dylib              0x1867e7294 _dispatch_lane_invoke$VARIANT$mp + 416
22 libdispatch.dylib              0x1867f078c _dispatch_workloop_worker_thread + 588
23 libsystem_pthread.dylib        0x18688bb74 _pthread_wqthread + 272
24 libsystem_pthread.dylib        0x18688e740 start_wqthread + 8

Summary:

• This change is a little different than https://github.com/bugsnag/bugsnag-react-native/pull/455 in that it just has .m files import their header files first thing.
• Also do not query TARGET_OS_MAC first as that is true for TARGET_IOS_SIMULATOR.

Test Plan:

• Debugging in Bugsnag for this code.
• I added a compiler error in every TARGET_OS_IPHONE conditional and ensured that they all worked. This is how I found the ones found in this diff.

Goal

Fix building Bugsnag via Bazel

Design

Ensure class headers are imported first, which brings in Foundation, which brings in TargetConditionals.h. This is typical code structure.

Changeset

Change the imports of files so that preprocessor macros are defined when read.

Tests

I added nonsense characters, to ensure that before the change would show that code wrapped in macro was not compiling, and that after the change it was. At runtime I was able to step into the BSGOutOfMemoryWatchdog which is usually preprocessor wrapped with BSGOOMAvailable, and it wasn't compiling for us.

Review

Outstanding Questions

• This pull request is ready for:
  • [ ] Initial review of the intended approach, not yet feature complete
  • [ ] Structural review of the classes, functions, and properties modified
  • [x] Final review
  • [ ] Release

• [x] The correct target branch has been selected (master for fixes, next for features)
• [ ] If this is intended for release have all of the pre-release checks been considered?
• [ ] Consistency across platforms for structures or concepts added or modified
• [ ] Consistency between the changeset and the goal stated above
• [ ] Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• [ ] Usage friction - is the proposed change in usage cumbersome or complicated?
• [ ] Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• [ ] Concurrency concerns - if components are accessed asynchronously, what issues will arise
• [ ] Thoroughness of added tests and any missing edge cases
• [ ] Idiomatic use of the language

This is the code I'm using:

	let isMainThead = Thread.isMainThread
	let error = NSError(domain: "co.recharge", code: 1)
	Bugsnag.notifyError(error, block: { report in
		report.errorMessage = message
		report.depth += 2 // Don't group by LogNonFatal always being at the top of the stack.
		report.addAttribute("isMainThread", withValue: isMainThead, toTabWithName: "extra")
	})

On average, 494ms on an iPhone SE. I'd stick it in an Async block but then the stacktrace wouldn't be correct :/

Goal

Enables automatic tracking of sessions by default, and adds a new API for setting the notify/session endpoints.

Design

This should prevent the unintentional scenario where a user sets the notify endpoint with a sessions endpoint.

Changeset

Added

setEndpointsForNotify:sessions:

Removed

Changed

• Updated docs for sessionURL and notifyURL to indicate they should be only used to read the value, not write.
• Auto capture flag is now true by default

Discussion

Outstanding Questions

• What should our approach be to deprecating the notifyURL and sessionURL properties? We may want to keep these properties to allow users to retrieve the value they have set. One option would be to deprecate them entirely, another would be to change to readonly rather than readwrite.

• What is our approach for writing mazerunner scenarios? We're missing scenarios for the session tracking feature entirely, so presumably we need to write these in addition to the new test cases in the design spec. Cocoa mazerunner scenarios also don't currently work on my machine, and I'm concerned that waiting 20-30 minutes for CI to run the scenarios is a very long feedback loop.

Review

For the submitter, initial self-review:

• [ ] Commented on code changes inline explain the reasoning behind the approach
• [ ] Reviewed the test cases added for completeness and possible points for discussion
• [ ] A changelog entry was added for the goal of this pull request
• [ ] Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • [x] Initial review of the intended approach, not yet feature complete
  • [ ] Structural review of the classes, functions, and properties modified
  • [ ] Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• [ ] Consistency across platforms for structures or concepts added or modified
• [ ] Consistency between the changeset and the goal stated above
• [ ] Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• [ ] Usage friction - is the proposed change in usage cumbersome or complicated?
• [ ] Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• [ ] Concurrency concerns - if components are accessed asynchronously, what issues will arise
• [ ] Thoroughness of added tests and any missing edge cases
• [ ] Idiomatic use of the language

Describe the bug

For some color, we use the configuration.addOnSendError block as a hook to send an event through our internal events pipeline. Recently, we've seen an increase in App Hang and Out of Memory events sent to our internal events db without ANY matching events in the Bugsnag dashboard for some users. For example, a single user has emitted 9k+ app hang events to our internal db and none to Bugsnag. These generally occur sometime after app launch and in rapid succession. We haven't been able to reproduce this yet, but we're trying to understand under what circumstances addOnSendError might be invoked multiple times for the same event. If Bugsnag fails to upload the event, would this block be invoked on retry, for instance?

We considered the possibility that our analytics publisher could be the culprit, but all events go through the same pipeline and these are the only events we see multiples of. Let me know if there's anything I can clarify or questions I can answer.

Steps to reproduce

1. No repro steps at this time

Environment

• Bugsnag version: 6.16.1
• CocoaPods version: N/A
• Carthage version (if any): N/A
• iOS/tvOS/macOS version(s): iOS 15.2
• Simulator or physical device: Device
• Xcode version: Xcode 13.2.1
• Swift version (if applicable):

Example Repo

• [ ] Create a minimal repository that can reproduce the issue
• [ ] Link to it here:

Example code snippet

# (Insert code sample to reproduce the problem)

I am using latest version of Bugsnag iOS SDK and have implemented manual build phase to upload symbols for symbolicating crashes.

I followed this doc https://docs.bugsnag.com/platforms/ios/symbolication-guide/#adding-a-build-phase-manually

After adding the script, my fastlane setup has started throwing issues. It cant export archives, neither for development nor for distribution.

Here is the snippet of my fastfile for archiving and uploading development build to firebase app distribution.

lane :beta do
    settings_to_override = {
      :BUNDLE_IDENTIFIER => "<Bundle ID>",
      :PROVISIONING_PROFILE_SPECIFIER => "<Profile Name>"
    }

    build_app(
        scheme: "<Scheme name>",
        export_method: "development",
        output_directory: "/Users/paras/Desktop",
	output_name: "<IPA>.ipa",
	xcargs: settings_to_override,
	export_options: {
       		provisioningProfiles: {"<bundle ID>" => "<profile name>"}
        }
    )
    
    firebase_app_distribution(
        app: "<ID>",
        groups: "Team"
    )
  end

I am not sure if I am doing anything wrong with the build phase but this issue started after we migrated to Bugsnag and changed the build phase.

Thanks

Describe the bug We're seeing a crash on the launch of our app. When Bugsnag is uninstalled, the app works fine.

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSDictionaryI setObject:forKeyedSubscript:]: unrecognized selector sent to instance 0x283290fc0'

When I add a breakpoint, it takes me to line 284 in BSGOutofMemoryWatchdog.m: contents[BSGKeyApp][APP_KEY_IS_MONITORING_OOM] = [self.kvStore NSBooleanForKey:KV_KEY_IS_MONITORING_OOM defaultValue:false];

Steps to reproduce Launching the app and starting Bugsnag on launch.

Environment Bugsnag version: 6.1.5 CocoaPods version: 1.9.3 Carthage version (if any): N/A iOS/tvOS/macOS version(s): iOS 13 or 14 so far Simulator or physical device: Physical device. Xcode version: Xcode 12 (12A7209) Swift version (if applicable): Swift 5

Describe the bug

Looks like a crash is happening from within the new network breadcrumbs plugin.

Steps to reproduce

CrashReporter Key:  d9416be80cce66b219bcc4c9ccccf351d909271f
Hardware Model:     iPad7,4
Process:            Primer
Identifier:         com.withprimer.Primer
Version:            1.7.1
Role:               Foreground
OS Version:         iOS 14.7.1


NSInvalidArgumentException: -[NSInvocation getArgument:atIndex:]: index (1) out of bounds [-1, 0]

0  CoreFoundation          -[NSInvocation getArgument:atIndex:]
1  CoreFoundation          -[NSInvocation selector]
2  Primer                  -[BSGURLSessionTracingProxy forwardInvocation:] (BSGURLSessionTracingProxy.m:51:32)
3  CoreFoundation          ____forwarding___
4  CoreFoundation          ___forwarding_prep_0___
5  CFNetwork               __CFNetworkHTTPConnectionCacheSetLimit
6  Foundation              ___NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__
7  Foundation              -[NSBlockOperation main]
8  Foundation              ___NSOPERATION_IS_INVOKING_MAIN__
9  Foundation              -[NSOperation start]
10 Foundation              ___NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__
11 Foundation              ___NSOQSchedule_f
12 libdispatch.dylib       __dispatch_block_async_invoke2
13 libdispatch.dylib       __dispatch_client_callout
14 libdispatch.dylib       __dispatch_continuation_pop$VARIANT$mp
15 libdispatch.dylib       __dispatch_async_redirect_invoke
16 libdispatch.dylib       __dispatch_root_queue_drain
17 libdispatch.dylib       __dispatch_worker_thread2
18 libsystem_pthread.dylib __pthread_wqthread
19 libsystem_pthread.dylib _start_wqthread

Environment

• Bugsnag version: 6.12.1
• CocoaPods version: N/A (SPM)
• Carthage version (if any): N/A (SPM)
• iOS/tvOS/macOS version(s): iOS 14.7.1
• Simulator or physical device: Physical device
• Xcode version: Xcode 13
• Swift version (if applicable): Swift 5.5

Example code snippet

  private func startBugsnag() {
    let configuration = BugsnagConfiguration(bugsnagAPIKey)
    configuration.add(BugsnagNetworkRequestPlugin())
    configuration.addOnSendError { event -> Bool in
      event.setCustomContextIfNeeded()
      event.trimStacktraceIfPossible()
      return true
    }
    Bugsnag.start(with: configuration)
  }

// MARK: - BugsnagEvent

private extension BugsnagEvent {
  
  func setCustomContextIfNeeded() {
    guard
      let contextualError = originalError as? ContextualError,
      let customContext = contextualError.customContext
    else {
      return
    }
    context = customContext
  }
  
  func trimStacktraceIfPossible() {
    errors.forEach {
      $0.trimStacktraceIfPossible()
    }
  }
}

// MARK: - BugsnagError

private extension BugsnagError {
  
  /// Represents the number of items we need to remove from a `BugsnagError`'s `stacktrace` before reporting
  /// the error.
  ///
  /// When using `LoggingService`, there are `2` extra items in the stacktrace that we need to account for:
  /// 1. The protocol witness for LoggingService to DefaultLoggingService
  /// 2. The call to notifyError(_:)
  private static let stackTraceItemsToRemoveCount = 2
  
  /// Removes the first `x` items from the `stacktrace` for the receiver, where
  /// `x` is `BugsnagError.stackTraceItemsToRemoveCount`.
  func trimStacktraceIfPossible() {
    guard stacktrace.count > BugsnagError.stackTraceItemsToRemoveCount else {
      return
    }
    stacktrace.removeFirst(BugsnagError.stackTraceItemsToRemoveCount)
  }
}

I am using swift package manager. I have added manual build phase script to upload the dsym files automatically whenever a build is archived/uploaded. The ruby script is not working. No dsym gets uploaded when any build is archived. However I was able to upload the dsym files manually from terminal using bugsnag-dsym-upload

I am using build phase script from the symbolication-guide under "Adding a build phase manually": symbolication Guide

Environment

• Bugsnag version: 6.25.1
• Xcode version: 14.0.1 , 14.1

Apparently calling NSProcessInfo.thermalState can trigger NSProcessInfoThermalStateDidChangeNotification so the NoteThermalState receiver needs to dispatch its call to access NSProcessInfo.thermalState on the object sent to it or it can trigger recursion that crashes the app. This appears to only happen ~10% of the time but we're not certain:

Description

I'm curious if there is any interest in increasing the general utility of the BugsnagNetworkRequestPlugin, especially for GraphQL APIs. What if, at the very least, the request and response bodies were sent over to Bugsnag?

By default, the URLRequests sent by GraphQL APIs don't end up providing very useful information when they make it over to Bugsnag: every request has the same URL, for example.

Describe the solution you'd like Since the BSGURLSessionTracingDelegate has access to the NSHTTPURLResponse when it comes time to log, what if we exposed a way for clients to parse the Data to a String however they'd like (I wouldn't want to assume JSON, but I'm interested in JSON personally) and that was included in the error information that gets sent up to Bugsnag?

Describe alternatives you've considered I'm aware of the ability to make some changes here server-side, but I'm mostly interested in having the bodies themselves show up in Bugsnag – regardless of whatever the web can do to change the URLs themselves.

Additional context This would make the plugin extremely useful for me, and I would prefer a built-in approach instead of dropping the plugin altogether and adding additional logging myself.

Description

It's hard to tell what the reason for a given Bugsnag OOM crash was - whether a crash was happened by a memory leak, a retain cycle or just a high memory usage caused but the lack of optimizations.

Describe the solution you'd like A way to tell whether a given OOM crash was a result of normal app usage (where the applications just happens to consume too much memory because of the lack of optimizations) or whether there is a memory leak / retain cycle somewhere in the app.

Describe alternatives you've considered Using Xcode instruments to profile the app - one can profile only a small subsets of all of the possible applications' configurations that production users experience. Looking at a Bugsnag report - even with a lot of breadcrumbs in it - it's hard to replicate the state a user was in and be able to tell whether their OOM crash was a result of a retain cycle / memory leak.

Additional context

I do not have a clear idea for how this could be implemented but I wonder whether Bugsnag team has any suggestions / tips / plans for features that could make it easier to detect whether a given OOM crash was a result of a memory leak or a retain cycle.

Description

Large iOS apps typically have multiple engineering teams that work on them. These teams typically work on a subset of features, comprised of a subset of modules in the app.

In this world, it's rather overwhelming to look at the giant list of crashes in Bugsnag and try to determine which are the ones you need to care about. Meanwhile, Bugsnag offers powerful functionality with Bookmarks, that allow engineers to create custom dashboards for a subset of crashes.

Describe the solution you'd like

We are very attracted to Sentry's ownership rules as a way of solving this problem. It allows engineers to filter based on file path or module. Meanwhile, Swift offers the #fileID macro and Obj-C offers the __FILE__ macro. Both of these would allow Bugsnag to attract file and module information for segmenting in Bugsnag.

We would love Bugsnag to incorporate some form of module-based or file-based filtering so that our feature teams can get a better handle on the crashes and errors that are most relevant to them.

Describe alternatives you've considered We have tried passing this in as metadata to Bugsnag. While this works for non-fatal errors since we know exactly when we're going to call notifyError, it does not work for crashes.

#927 was a previous form of this request, but we believe the approach in this new issue is much more straightforward.

Description

It would be nice to know "why is the app launching?" Basically we'd like to know if we're re-launching due to a crash, or an OOM, etc. This will allow us to monitor what is going wrong more closely.

Describe the solution you'd like Right now there is +[Bugsnag appDidCrashLastLaunch]. How about an enumeration about why the application launched? Something along the lines of https://eng.uber.com/startup-reason-reporter/

Describe alternatives you've considered Right now we use private interfaces in Bugsnag to get -[BSGOutOfMemoryWatchdog didOOMLastLaunch] in v5, and -[BugsnagClient shouldReportOOM] in v6

Related requests with #570.

Additional context We basically just want to monitor with our own services if Bugsnag believes an OOM has occurred.