bugsnag-cocoa: Messages from fatalError/etc are no longer propagated on Bugsnag reports

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?

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 30 (11 by maintainers)

Commits related to this issue

fix: Strip top bits from pointers before reading memory contents In the new Xcode 10 build system, Swift object register values have the top bit used as a flag. This change strips the flag while not ... — committed to bugsnag/bugsnag-cocoa by kattrali 6 years ago
fix: Strip top bits from pointers before reading memory contents In the new Xcode 10 build system, Swift object register values have the top bit used as a flag. This change strips the flag while not ... — committed to bugsnag/bugsnag-cocoa by kattrali 6 years ago
fix: Strip top bits from pointers before reading memory contents In the new Xcode 10 build system, Swift object register values have the top bit used as a flag. This change strips the flag while not ... — committed to bugsnag/bugsnag-cocoa by kattrali 6 years ago
fix: Strip top bits from pointers before reading memory contents In the new Xcode 10 build system, Swift object register values have the top bit used as a flag. This change strips the flag while not ... — committed to bugsnag/bugsnag-cocoa by kattrali 6 years ago

Most upvoted comments

We’ve now implemented a new approach to extracting the error messages from Swift’s assertionFailure, fatalError, and preconditionFailure functions, which has been released in v6.5.0.

For further details see: https://github.com/bugsnag/bugsnag-cocoa/pull/948

mattdyoung on Jan 6, 2021

Hi @sethfri,

We are working on this at the moment, although we don’t have any definite timeframe as yet. We will share any updates here as we have them.

johnkiely1 on Dec 15, 2020

Hi there, is there any update on this? This is something Crashlytics already does correctly, and we’re disappointed to see Bugsnag doesn’t

sethfri on Dec 15, 2020

From that thread:

The Swift compiler in development now emits fatal error traps with an artificial inline frame, which will allow crash reporters than understand debug info to show the error directly as part of the backtrace. Future toolchains that include this change should be able to do better.

Does this mean BugSnag has the ability to fix this now? If so, how long will it take?

sjmueller on Jun 4, 2020

I just stumbled upon the same issue. The message we pass to fatalError is 18 characters long. There’s a message included in the crash report, but its not the one we passed to fatalError.

To debug this, I took a look at the crashing binary with Hopper Disassembler and found that the error message that was passed to fatalError (“Test for Log.fatal”) is stored at 0x1006c28f0, while the message that the crash handler included into the report ("al data for MSCB ") is located at 0x1006c28d0, which is just 32 (0x20) less than the correct address. There seems to be an error in the offset that the crash handler uses to determine the location of the message.

This is in a simulator build for x86_64. Compiler is swiftlang-1100.0.282.1 clang-1100.0.33.15 from Xcode 11.3.1 (11C505).

tiwoc on Mar 2, 2020

Hi. Is there any news on that? It’s been on hold for a while now. Thanks 😃

Nemixdre on Jan 28, 2020

@kattrali iPhone SE. Swift 4.2, Xcode 10.0 (10A255)

edenman on Dec 3, 2018