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