intercept fatalError() or other termination messages from swift?

I realize this is slightly centric to iOS, but it irks me that both Apple’s crash report logs and popular platforms like PLCrashReporter can do the hard stuff like give you a stack trace, but are *completely* unable to display the error message from terminating a program via fatalError(), or the error message from, e.g. dying with a bad optional.

Is there *any* to intercept the error messages that from fatalError() and similar like things in swift (bad optionals, invalid array accesses, assertions)? I would think that some sort of a “hook” into these standard error routines would be a good thing.

In my case, if I could simply save that darn error string in a file, i could pick it up when the app next launches and report it along with the rest of the info like the stack/signal, etc.

I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but haven’t found anything promising that lets me jump in there. In my code, I’m likely to write things like
  guard let x = … else {
    fatalError(“Data type has payload <T> but is hooked to UI control with intrinsic type <U>”)
  }

and having that exact string tells me precisely what’s going, far simpler than a stack trace.

Crashlytics can pick up these strings just fine. I thought they were part of the full crash dump.

···

On Jun 24, 2017, at 12:13 AM, David Baraff via swift-users <swift-users@swift.org> wrote:

I realize this is slightly centric to iOS, but it irks me that both Apple’s crash report logs and popular platforms like PLCrashReporter can do the hard stuff like give you a stack trace, but are *completely* unable to display the error message from terminating a program via fatalError(), or the error message from, e.g. dying with a bad optional.

Is there *any* to intercept the error messages that from fatalError() and similar like things in swift (bad optionals, invalid array accesses, assertions)? I would think that some sort of a “hook” into these standard error routines would be a good thing.

In my case, if I could simply save that darn error string in a file, i could pick it up when the app next launches and report it along with the rest of the info like the stack/signal, etc.

I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but haven’t found anything promising that lets me jump in there. In my code, I’m likely to write things like
   guard let x = … else {
       fatalError(“Data type has payload <T> but is hooked to UI control with intrinsic type <U>”)
   }

and having that exact string tells me precisely what’s going, far simpler than a stack trace.

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Fatal error messages already get logged three ways:

- Printed to the process's stderr;
- Logged to the system log using asl_log;
- Set as the crash reason for CrashReporter.

The crash messages should thus already be in your crash reports somewhere. See https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L168 and https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L204 for the relevant runtime source code. cc'ing Greg Parker who probably knows better exactly where these messages end up.

-Joe

···

On Jun 23, 2017, at 9:13 PM, David Baraff via swift-users <swift-users@swift.org> wrote:

I realize this is slightly centric to iOS, but it irks me that both Apple’s crash report logs and popular platforms like PLCrashReporter can do the hard stuff like give you a stack trace, but are *completely* unable to display the error message from terminating a program via fatalError(), or the error message from, e.g. dying with a bad optional.

Is there *any* to intercept the error messages that from fatalError() and similar like things in swift (bad optionals, invalid array accesses, assertions)? I would think that some sort of a “hook” into these standard error routines would be a good thing.

In my case, if I could simply save that darn error string in a file, i could pick it up when the app next launches and report it along with the rest of the info like the stack/signal, etc.

I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but haven’t found anything promising that lets me jump in there. In my code, I’m likely to write things like
  guard let x = … else {
    fatalError(“Data type has payload <T> but is hooked to UI control with intrinsic type <U>”)
  }

and having that exact string tells me precisely what’s going, far simpler than a stack trace.

Is it possible that Apple’s own xcode tools just don’t show you the string, but it’s there anyway? that seems pretty bogus…

···

On Jun 23, 2017, at 9:40 PM, Jon Shier via swift-users <swift-users@swift.org> wrote:

Crashlytics can pick up these strings just fine. I thought they were part of the full crash dump.

On Jun 24, 2017, at 12:13 AM, David Baraff via swift-users <swift-users@swift.org> wrote:

I realize this is slightly centric to iOS, but it irks me that both Apple’s crash report logs and popular platforms like PLCrashReporter can do the hard stuff like give you a stack trace, but are *completely* unable to display the error message from terminating a program via fatalError(), or the error message from, e.g. dying with a bad optional.

Is there *any* to intercept the error messages that from fatalError() and similar like things in swift (bad optionals, invalid array accesses, assertions)? I would think that some sort of a “hook” into these standard error routines would be a good thing.

In my case, if I could simply save that darn error string in a file, i could pick it up when the app next launches and report it along with the rest of the info like the stack/signal, etc.

I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but haven’t found anything promising that lets me jump in there. In my code, I’m likely to write things like
  guard let x = … else {
      fatalError(“Data type has payload <T> but is hooked to UI control with intrinsic type <U>”)
  }

and having that exact string tells me precisely what’s going, far simpler than a stack trace.

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

To be very clear, i’m concerned about iOS not mac os x. I pulled up a crash report using xcode tools, and saw no mention of the string output by fatal error. If there is someway after the fact of, on an iPhone or iOS interogating the asl_log when you restart your program to glean the error message, i’m all ears.

···

On Jun 26, 2017, at 10:01 AM, Joe Groff <jgroff@apple.com> wrote:

On Jun 23, 2017, at 9:13 PM, David Baraff via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

I realize this is slightly centric to iOS, but it irks me that both Apple’s crash report logs and popular platforms like PLCrashReporter can do the hard stuff like give you a stack trace, but are *completely* unable to display the error message from terminating a program via fatalError(), or the error message from, e.g. dying with a bad optional.

Is there *any* to intercept the error messages that from fatalError() and similar like things in swift (bad optionals, invalid array accesses, assertions)? I would think that some sort of a “hook” into these standard error routines would be a good thing.

In my case, if I could simply save that darn error string in a file, i could pick it up when the app next launches and report it along with the rest of the info like the stack/signal, etc.

I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but haven’t found anything promising that lets me jump in there. In my code, I’m likely to write things like
  guard let x = … else {
    fatalError(“Data type has payload <T> but is hooked to UI control with intrinsic type <U>”)
  }

and having that exact string tells me precisely what’s going, far simpler than a stack trace.

Fatal error messages already get logged three ways:

- Printed to the process's stderr;
- Logged to the system log using asl_log;
- Set as the crash reason for CrashReporter.

The crash messages should thus already be in your crash reports somewhere. See https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L168 and https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L204 for the relevant runtime source code. cc'ing Greg Parker who probably knows better exactly where these messages end up.

-Joe

The fatal error message ought to appear under the "Application Specific Information:" heading in the crash report Xcode pulls from the device.

-Joe

···

On Jun 26, 2017, at 12:22 PM, David Baraff <davidbaraff@gmail.com> wrote:

To be very clear, i’m concerned about iOS not mac os x. I pulled up a crash report using xcode tools, and saw no mention of the string output by fatal error. If there is someway after the fact of, on an iPhone or iOS interogating the asl_log when you restart your program to glean the error message, i’m all ears.

If you export the crash from Xcode, do you see the string in the raw report?

Jon

···

On Jun 26, 2017, at 3:22 PM, David Baraff via swift-users <swift-users@swift.org> wrote:

To be very clear, i’m concerned about iOS not mac os x. I pulled up a crash report using xcode tools, and saw no mention of the string output by fatal error. If there is someway after the fact of, on an iPhone or iOS interogating the asl_log when you restart your program to glean the error message, i’m all ears.

On Jun 26, 2017, at 10:01 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Jun 23, 2017, at 9:13 PM, David Baraff via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

I realize this is slightly centric to iOS, but it irks me that both Apple’s crash report logs and popular platforms like PLCrashReporter can do the hard stuff like give you a stack trace, but are *completely* unable to display the error message from terminating a program via fatalError(), or the error message from, e.g. dying with a bad optional.

Is there *any* to intercept the error messages that from fatalError() and similar like things in swift (bad optionals, invalid array accesses, assertions)? I would think that some sort of a “hook” into these standard error routines would be a good thing.

In my case, if I could simply save that darn error string in a file, i could pick it up when the app next launches and report it along with the rest of the info like the stack/signal, etc.

I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but haven’t found anything promising that lets me jump in there. In my code, I’m likely to write things like
  guard let x = … else {
    fatalError(“Data type has payload <T> but is hooked to UI control with intrinsic type <U>”)
  }

and having that exact string tells me precisely what’s going, far simpler than a stack trace.

Fatal error messages already get logged three ways:

- Printed to the process's stderr;
- Logged to the system log using asl_log;
- Set as the crash reason for CrashReporter.

The crash messages should thus already be in your crash reports somewhere. See https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L168 and https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L204 for the relevant runtime source code. cc'ing Greg Parker who probably knows better exactly where these messages end up.

-Joe

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

From: Jon Shier <jon@jonshier.com>
Subject: Re: [swift-users] intercept fatalError() or other termination messages from swift?
Date: June 26, 2017 at 12:30:50 PM PDT
To: David Baraff <davidbaraff@gmail.com>
Cc: Joe Groff <jgroff@apple.com>, swift-users <swift-users@swift.org>

If you export the crash from Xcode, do you see the string in the raw report?

No.

···

Begin forwarded message:

Jon

On Jun 26, 2017, at 3:22 PM, David Baraff via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

To be very clear, i’m concerned about iOS not mac os x. I pulled up a crash report using xcode tools, and saw no mention of the string output by fatal error. If there is someway after the fact of, on an iPhone or iOS interogating the asl_log when you restart your program to glean the error message, i’m all ears.

On Jun 26, 2017, at 10:01 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Jun 23, 2017, at 9:13 PM, David Baraff via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

I realize this is slightly centric to iOS, but it irks me that both Apple’s crash report logs and popular platforms like PLCrashReporter can do the hard stuff like give you a stack trace, but are *completely* unable to display the error message from terminating a program via fatalError(), or the error message from, e.g. dying with a bad optional.

Is there *any* to intercept the error messages that from fatalError() and similar like things in swift (bad optionals, invalid array accesses, assertions)? I would think that some sort of a “hook” into these standard error routines would be a good thing.

In my case, if I could simply save that darn error string in a file, i could pick it up when the app next launches and report it along with the rest of the info like the stack/signal, etc.

I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but haven’t found anything promising that lets me jump in there. In my code, I’m likely to write things like
  guard let x = … else {
    fatalError(“Data type has payload <T> but is hooked to UI control with intrinsic type <U>”)
  }

and having that exact string tells me precisely what’s going, far simpler than a stack trace.

Fatal error messages already get logged three ways:

- Printed to the process's stderr;
- Logged to the system log using asl_log;
- Set as the crash reason for CrashReporter.

The crash messages should thus already be in your crash reports somewhere. See https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L168 and https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L204 for the relevant runtime source code. cc'ing Greg Parker who probably knows better exactly where these messages end up.

-Joe

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

I will do a few more crashes, by doing a fatalError() and also unwrapping an optional or something, and see if I can see them. THanks for telling me where to look. I’ll let you know what I find.

···

Begin forwarded message:

From: Joe Groff <jgroff@apple.com>
Subject: Re: [swift-users] intercept fatalError() or other termination messages from swift?
Date: June 26, 2017 at 1:22:33 PM PDT
To: David Baraff <davidbaraff@gmail.com>
Cc: Greg Parker <gparker@apple.com>, swift-users <swift-users@swift.org>

On Jun 26, 2017, at 12:22 PM, David Baraff <davidbaraff@gmail.com> wrote:

To be very clear, i’m concerned about iOS not mac os x. I pulled up a crash report using xcode tools, and saw no mention of the string output by fatal error. If there is someway after the fact of, on an iPhone or iOS interogating the asl_log when you restart your program to glean the error message, i’m all ears.

The fatal error message ought to appear under the "Application Specific Information:" heading in the crash report Xcode pulls from the device.

-Joe

Ok, the data is for sure not there, or possibly i’m looking at the wrong thing. Here is what I see:

Incident Identifier: 15D12BCE-975B-47B6-BD03-DD8512D40DAF
CrashReporter Key: 8af1402ae87b0184acff113b3f7312743d94d074
Hardware Model: iPad6,7
Process: hackyApp [4965]
Path: /private/var/containers/Bundle/Application/29195F7D-7548-4917-93D8-2B027481EAFB/hackyApp.app/hackyApp
Identifier: deb.hackyApp
Version: 1 (1.1)
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: deb.hackyApp [5747]

Date/Time: 2017-06-26 19:38:48.2905 -0700
Launch Time: 2017-06-26 19:38:48.1510 -0700
OS Version: iPhone OS 10.3.2 (14F89)
Report Version: 104

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000010045f734
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [0]
Triggered by Thread: 0

Filtered syslog:
None found

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libswiftCore.dylib 0x000000010045f734 0x100304000 + 1423156
1 libswiftCore.dylib 0x000000010045f734 0x100304000 + 1423156
2 hackyApp 0x00000001000b0708 0x1000a8000 + 34568
3 hackyApp 0x00000001000b08c0 0x1000a8000 + 35008
4 UIKit 0x000000019822cec0 -[UIViewController loadViewIfRequired] + 1036

The stack trace continues for a while, then a list of binary images. There is nothing that says "Application Specific Information”. Am I pulling the wrong data in xcode? Is my app setup in a weird way that this is not reported?

This is doing the very simple “fatalError()” route in the main controller's viewDidLoad() routine.

Thanks for any insights.

···

On Jun 26, 2017, at 1:22 PM, Joe Groff <jgroff@apple.com> wrote:

On Jun 26, 2017, at 12:22 PM, David Baraff <davidbaraff@gmail.com> wrote:

To be very clear, i’m concerned about iOS not mac os x. I pulled up a crash report using xcode tools, and saw no mention of the string output by fatal error. If there is someway after the fact of, on an iPhone or iOS interogating the asl_log when you restart your program to glean the error message, i’m all ears.

The fatal error message ought to appear under the "Application Specific Information:" heading in the crash report Xcode pulls from the device.

-Joe

Unfortunately, it looks like iOS on-device prunes the application-specific info from crash logs because of user privacy concerns. The crash reason does show up in macOS or simulator crash logs, however.

-Joe

···

On Jun 26, 2017, at 7:45 PM, David Baraff <davidbaraff@gmail.com> wrote:

Ok, the data is for sure not there, or possibly i’m looking at the wrong thing. Here is what I see:

Incident Identifier: 15D12BCE-975B-47B6-BD03-DD8512D40DAF
CrashReporter Key: 8af1402ae87b0184acff113b3f7312743d94d074
Hardware Model: iPad6,7
Process: hackyApp [4965]
Path: /private/var/containers/Bundle/Application/29195F7D-7548-4917-93D8-2B027481EAFB/hackyApp.app/hackyApp
Identifier: deb.hackyApp
Version: 1 (1.1)
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: deb.hackyApp [5747]

Date/Time: 2017-06-26 19:38:48.2905 -0700
Launch Time: 2017-06-26 19:38:48.1510 -0700
OS Version: iPhone OS 10.3.2 (14F89)
Report Version: 104

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000010045f734
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [0]
Triggered by Thread: 0

Filtered syslog:
None found

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libswiftCore.dylib 0x000000010045f734 0x100304000 + 1423156
1 libswiftCore.dylib 0x000000010045f734 0x100304000 + 1423156
2 hackyApp 0x00000001000b0708 0x1000a8000 + 34568
3 hackyApp 0x00000001000b08c0 0x1000a8000 + 35008
4 UIKit 0x000000019822cec0 -[UIViewController loadViewIfRequired] + 1036

The stack trace continues for a while, then a list of binary images. There is nothing that says "Application Specific Information”. Am I pulling the wrong data in xcode? Is my app setup in a weird way that this is not reported?

This is doing the very simple “fatalError()” route in the main controller's viewDidLoad() routine.

Thanks for any insights.