RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash reporting

[Thomas Stuefe]

On Wed, 22 Feb 2023 07:47:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Do we actually need UseOSErrorReporting? Honest question since I have personally never used it. Whenever I wanted to debug a problem on windows, I used the minidump write facility.
> 
> This was recently discussed in https://bugs.openjdk.org/browse/JDK-8250782
> 
> specifically the reply from @mo-beck https://bugs.openjdk.org/browse/JDK-8250782?focusedCommentId=14553883&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14553883
> 
> So yes, we do want to keep it.

Okay, I see. But does it have to come with hs-err file too? Because that is the only reason for this complication. And hs-err files probably spoil the context reported to Watson, see below.

I am unhappy with this patch because it "sanctifies" returning from hs-err reporting. We had long and intense discussions in the recent past where we needed to convince developers that returning from hs-err reporting is a very bad idea. I'm afraid with your patch, it won't be long before follow-up patches build upon your ARA and re-introduce this question.

I'd prefer if UseOSErrorReporting, and all this code surrounding the windows exceptionhandler and CONTINUE_SEARCH, remained Windows only, and restricted to this one use case: jumping back to OS error reporting in case of an error.

Your patch opens up other questions too, e.g. how is this supposed to work in the face of secondary errors? IIUC the last invocation of the exception handler would be the winning one and return its error state back to the top-level exception filter, so the error reported by Watson would be the secondary crash, not the real crash. I think this would happen today too, or?

This may be an argument for skipping hs-err reporting with UseOSErrorReporting - skipping everything, actually: the context that gets reported to Watson would be guaranteed to be the one from the real crash point. And the crash would be "fresh", as close as possible to the real crash site. I'd think that this is how UseOSErrorReporting is supposed to work, leaving crash reporting up to the OS.

-------------

PR: https://git.openjdk.org/jdk/pull/12651