| commit | 9aab5273dd8f1a516c4f072b350487a50cc0bced | |
| author | Alexander Kyte <alexmkyte@gmail.com> | |
| Fri, 19 Oct 2018 00:39:03 +0000 (18 20:39 -0400) | ||
| committer | Alexander Köplinger <alex.koeplinger@outlook.com> | |
| Fri, 19 Oct 2018 00:39:03 +0000 (19 02:39 +0200) | ||
| tree | f538100ae4e9f7d06421595970be7f9a40cceb37 | treesnapshot (tar.gz zip) |
| parent | 4844ab019dc4c04eb5b96dceca32a84a6256dff5 | commitdiff |
Add crash reporting debugger event (#10628)
This should help get information on native crashes that happen in hard-to-debug environments.
To quote https://github.com/mono/mono/issues/10157 :
When a mono runtime is attached to a managed debugger and the debugged runtime is induced to cause a crash, the state of that crash is not communicated to the managed debugger. This, combined with the difficulty in having the debugged runtime both attached to the managed debugger and lldb, makes this type of crash difficult to interactively debug.
When the managed debugger is the only connection someone has with the runtime because it is embedded in a way that is resistant to unmanaged debugging (watchOS application on-device, for instance), this is an even more difficult problem.
By adding an SDB protocol event that sends a type of "runtime death" and a blob of opaque json (version dependent, no protocol guarantees), people can report these crashes without having to assist a mono runtime engineer in observing a crash on device.
In the case that spurious bugs in this manner are submitted, it will require less effort as well to spot stack frames that indicate misuse of mixed managed-unmanaged APIs (which offer the ability to drive a segfault or g_assert
This should help get information on native crashes that happen in hard-to-debug environments.
To quote https://github.com/mono/mono/issues/10157 :
When a mono runtime is attached to a managed debugger and the debugged runtime is induced to cause a crash, the state of that crash is not communicated to the managed debugger. This, combined with the difficulty in having the debugged runtime both attached to the managed debugger and lldb, makes this type of crash difficult to interactively debug.
When the managed debugger is the only connection someone has with the runtime because it is embedded in a way that is resistant to unmanaged debugging (watchOS application on-device, for instance), this is an even more difficult problem.
By adding an SDB protocol event that sends a type of "runtime death" and a blob of opaque json (version dependent, no protocol guarantees), people can report these crashes without having to assist a mono runtime engineer in observing a crash on device.
In the case that spurious bugs in this manner are submitted, it will require less effort as well to spot stack frames that indicate misuse of mixed managed-unmanaged APIs (which offer the ability to drive a segfault or g_assert
16 files changed: