Messages from fatalError/etc are no longer propagated on Bugsnag reports #318

edenman · 2018-11-05T23:42:57Z

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?

The text was updated successfully, but these errors were encountered:

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 losing anything relevant to us in our quest to see error messages for assertion failures. Fixes #318

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 losing anything relevant to us in our quest to see error messages for assertion failures. This technique does not capture messages which are less than 16 characters, as short strings are stored as raw char arrays on the stack rather than being allocated. (See WWDC 2018 #401 for more info on new string optimizations) While it is possible to check for char arrays as well as pointers when searching for notable address values, sweeping up local variables has a likely chance of capturing unintended data as well from the surrounding code, some of which may be sensitive. It is also not guaranteed that the value would still be on the stack after the message is logged, so it is possible to get only unrelated string values as the message. In the current Swift stdlib, the following messages passed to fatalError, preconditionFailure, and precondition (and their internal func counterparts) are less than 16 characters: * empty string * `unavailable` * `not implemented` * `abstract method` * `unknown value` * `invalid count` (where a dictionary contains < 0 items(?)) * `invalid index` (where a dictionary ceases to be a dictionary) * `don't touch me` (from SpriteKit) * `close() failed` (from the private Subprocess implementation) The vast majority have more meaningful messages. Reference: * https://asciiwwdc.com/2018/sessions/401 Fixes #318

edenman · 2018-12-03T16:44:40Z

I just updated to Bugsnag 5.17.1 and the issue is still not fixed. I tried both on a dev build and an ad-hoc distribution, no luck getting the fatalError message on either:

dev build https://app.bugsnag.com/recharge-labs/ios-consumer/errors/5c05587150c99b001aa35ac0
production https://app.bugsnag.com/recharge-labs/ios-consumer/errors/5c055ca9638ce3001a10ce8d

snmaynard · 2018-12-03T16:47:33Z

"i am a message" is less than 16 characters and is no longer possible to show. If you have a message of more than 16 characters it should work

edenman · 2018-12-03T17:02:36Z

Same issue, even with a message longer than 16 characters ("Eric test crash..") https://app.bugsnag.com/recharge-labs/ios-consumer/errors/5c0560f209f364001a4947be

kattrali · 2018-12-03T17:29:53Z

@edenman What device? I can try to reproduce and figure out what's going on.

edenman · 2018-12-03T17:34:55Z

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

kattrali · 2018-12-03T19:32:33Z

It seems to be working for me in a reduced test case using:

iPhone SE + Swift 4.2 + Xcode 10.0 (10A255)
iPhone SE + Swift 4.2 + Xcode 10.1 (10B61)

In both debug and production builds, and I tried a few different strings to rule out any weirdness.

I updated the test project here (on the kattrali/upgrade-swift-ios-project branch) with the settings I'm using. Can you try it on your machine to see if it also works for you? If it does, perhaps we can see if a particular setting is causing different behavior.

edenman · 2018-12-03T19:52:46Z

I just ran the test project, although I had to tweak a few things to get it working. Do you see the crashes I forced? I'm guessing they're being uploaded to a project that I don't have access to.

kattrali · 2018-12-03T21:11:33Z

By default there's no API key set, so you'd have to add one in the app delegate.

edenman · 2018-12-03T23:52:36Z

Derp. Ok, yeah, it's working fine in the sample app. Not sure why it's not working in my actual app.

sjmueller · 2019-06-04T21:16:02Z

Can this be re-opened? I have same problem, anytime we invoke fatalError("custom message"), we get a blank message in bugsnag:

Our release builds to the App Store use bitcode, could that be affecting things?

snmaynard · 2019-06-04T22:59:59Z

@sjmueller "custom message" is less than 16 characters so would be known not to work. Are you actually trying with that string or a longer one?

sjmueller · 2019-06-05T08:00:14Z

Correct, we are experiencing this with more than 16 characters. Example: this is the line for Actions.swift:742:

guard routes.last != route.rawValue else { fatalError("Attempted to push the same route twice") }

sjmueller · 2019-07-10T21:57:12Z

Any update here? This is leaving us in the dark with our bug reports.

edenman · 2019-07-10T22:00:47Z

@sjmueller I wasn't able to figure out what was causing this. I ended up just wrapping all fatalError calls in my own helper method that first adds a breadcrumb and then calls fatalError. It sucks, but /shrug

snmaynard · 2019-07-10T22:14:41Z

The problem is with different versions of swift or the compiler that the memory location that this information in changes. I believe that we have to reach into specific registers to find it, and it depends on how long the string is as to where the information is. The reality is that swift needs to make an API for this so we can fetch it which I believe @kattrali is thinking about.

sjmueller · 2019-09-13T07:14:46Z

@snmaynard but that doesn't make too much sense if @edenman is writing the error to a breadcrumb before invoking the fatalError. If he's able to write the information to the breadcrumbs portion of the api, then why can't it be written to the right place automatically?

snmaynard · 2019-09-13T18:44:54Z

That's because he is doing it before calling fatalError. There is no API from a crash handler to get access to this information. We have to inspect registers to get it - and it's not reliable.

sjmueller · 2019-09-13T23:19:03Z

Thanks for the response. Do you have an alternative suggestion to invoking fatalError that would enable bugsnag to capture exceptions in these scenarios? In the case of fatalError it's our code invoking, so we could change to another pattern pretty quickly.

snmaynard · 2019-09-14T00:21:29Z

@kattrali may have some ideas - but what @edenman has done with wrapping it and adding a breadcrumb doesn't seem terrible to me. I'll see if I can think of other ideas - its annoying we cant get access to the data in the crash handler - I think @kattrali was looking to see if a proposal could be made to swift to change that.

edenman · 2019-09-14T00:30:36Z

My workaround works but it breaks grouping. And the issue I opened on that problem is stuck too: #226

Nemixdre · 2020-01-28T09:01:40Z

Hi. Is there any news on that? It's been on hold for a while now.
Thanks :)

tiwoc · 2020-03-02T13:41:27Z

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).

xljones · 2020-03-10T16:37:52Z

Hey @Nemixdre, until we've got something more concrete from Swift, this isn't going to be progressed, unfortunately. As noted above, the locations for this data moves depending on a few factors, without a single and robust method for us to gather the data. We've made a proposal to Swift to make this change and are following any responses closely, we'll report back here as soon as there are any updates! :)

sjmueller · 2020-06-04T07:35:53Z

If we were to run Instabug in parallel, would they have the same exact problems? In other words, is this a Bugsnag issue or one that is unsolvable across the entire space?

tiwoc · 2020-06-04T09:33:44Z

For anyone wondering, the Swift proposal that was mentioned earlier in this thread is likely this one: Cleanup callback for fatal Swift errors

sjmueller · 2020-06-04T22:14:00Z

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?

xljones · 2020-06-09T16:08:44Z

Hey @sjmueller, it looks like this may now be possible. We'll take a look into this as priorities allow.

sethfri · 2020-12-15T08:41:06Z

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

johnkiely1 · 2020-12-15T10:04:08Z

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.

mattdyoung · 2021-01-06T15:01:00Z

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:
#948

kattrali mentioned this issue Nov 29, 2018

Strip top bits from pointers before reading memory contents #320

Merged

5 tasks

kattrali closed this as completed in #320 Nov 30, 2018

tomlongridge reopened this Jun 6, 2019

abigailbramble added needs discussion Requires internal analysis/discussion scheduled Work is starting on this feature/bug labels Sep 3, 2019

philipphofmann mentioned this issue Nov 20, 2020

fatalError call with message does not report message value in Sentry Dashboard getsentry/sentry-cocoa#662

Closed

sethfri mentioned this issue Dec 18, 2020

Propagate Error from try! #950

Closed

mattdyoung added bug Confirmed bug released This feature/bug fix has been released and removed needs discussion Requires internal analysis/discussion scheduled Work is starting on this feature/bug labels Jan 6, 2021

mattdyoung closed this as completed Jan 6, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Messages from fatalError/etc are no longer propagated on Bugsnag reports #318

Messages from fatalError/etc are no longer propagated on Bugsnag reports #318

edenman commented Nov 5, 2018

edenman commented Dec 3, 2018

snmaynard commented Dec 3, 2018

edenman commented Dec 3, 2018

kattrali commented Dec 3, 2018

edenman commented Dec 3, 2018

kattrali commented Dec 3, 2018

edenman commented Dec 3, 2018 •

edited

Loading

kattrali commented Dec 3, 2018

edenman commented Dec 3, 2018

sjmueller commented Jun 4, 2019

snmaynard commented Jun 4, 2019

sjmueller commented Jun 5, 2019

sjmueller commented Jul 10, 2019

edenman commented Jul 10, 2019

snmaynard commented Jul 10, 2019

sjmueller commented Sep 13, 2019

snmaynard commented Sep 13, 2019

sjmueller commented Sep 13, 2019

snmaynard commented Sep 14, 2019

edenman commented Sep 14, 2019

Nemixdre commented Jan 28, 2020

tiwoc commented Mar 2, 2020 •

edited

Loading

xljones commented Mar 10, 2020

sjmueller commented Jun 4, 2020

tiwoc commented Jun 4, 2020

sjmueller commented Jun 4, 2020

xljones commented Jun 9, 2020

sethfri commented Dec 15, 2020

johnkiely1 commented Dec 15, 2020

mattdyoung commented Jan 6, 2021

Messages from fatalError/etc are no longer propagated on Bugsnag reports #318

Messages from fatalError/etc are no longer propagated on Bugsnag reports #318

Comments

edenman commented Nov 5, 2018

Expected behavior

Observed behavior

Version

Additional information

edenman commented Dec 3, 2018

snmaynard commented Dec 3, 2018

edenman commented Dec 3, 2018

kattrali commented Dec 3, 2018

edenman commented Dec 3, 2018

kattrali commented Dec 3, 2018

edenman commented Dec 3, 2018 • edited Loading

kattrali commented Dec 3, 2018

edenman commented Dec 3, 2018

sjmueller commented Jun 4, 2019

snmaynard commented Jun 4, 2019

sjmueller commented Jun 5, 2019

sjmueller commented Jul 10, 2019

edenman commented Jul 10, 2019

snmaynard commented Jul 10, 2019

sjmueller commented Sep 13, 2019

snmaynard commented Sep 13, 2019

sjmueller commented Sep 13, 2019

snmaynard commented Sep 14, 2019

edenman commented Sep 14, 2019

Nemixdre commented Jan 28, 2020

tiwoc commented Mar 2, 2020 • edited Loading

xljones commented Mar 10, 2020

sjmueller commented Jun 4, 2020

tiwoc commented Jun 4, 2020

sjmueller commented Jun 4, 2020

xljones commented Jun 9, 2020

sethfri commented Dec 15, 2020

johnkiely1 commented Dec 15, 2020

mattdyoung commented Jan 6, 2021

edenman commented Dec 3, 2018 •

edited

Loading

tiwoc commented Mar 2, 2020 •

edited

Loading