Open Radar

 
Summary:
Our CI system runs our tests on iOS Simulators, and sometimes we encounter crashes for bugs in our code.

In rdar://40830829, I've called out that we don't have a signal for when a crash is in process of being symbolicated so that we can wait for it in CI and/or kick something to synchronously complete processing.

I noticed today some crashes that took a long time to symbolicate (from a recursive method leading to a stack overflow), and ended up getting generated during the subsequent CI job and attached as a failure for that crash. On opening the crash logs, it appears that the `Date/Time` that is in the `.crash` file is not from when the crash occurred, but from some other time later in the crash processing pipeline.

```
Date/Time:             2018-07-27 10:54:45.357 -0700
```

Barring a way to get crash information for test runs as part of the testing process (rdar://40830829), it would be great if there were a way to make this date/time reflect the time that the crash occurred so we can filter out crash files that weren't caused by the current run.

Steps to Reproduce:
1. Have a test running within an AppHost that crashes the host apps process.
 * In the test, output the system time just before the crash is triggered
 * Potentially having it be a stack overflow might make it take longer to symbolicate.
 * It is also possible that having it be for an app with a massive compiled app binary (static and dynamic frameworks) causes the symbolication process to take longer.
2. When the crash file is generated under ~/Library/Logs/DiagnosticReports, compare the "Date/Time" in the crash file to the time from running the test

Expected Results:
The crash time should reflect the time that the crash occurred.

Actual Results:
The crash time should reflect the time that the crash is being processed.

Version/Build:
Mac OS X 10.13.3 (17D47)
Xcode 9.4 - Build version 9F1027a

Configuration: