Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report #4006

Closed
wants to merge 3 commits into from

Conversation

dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented May 13, 2021

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that.

Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4006/head:pull/4006
$ git checkout pull/4006

Update a local copy of the PR:
$ git checkout pull/4006
$ git pull https://git.openjdk.java.net/jdk pull/4006/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4006

View PR using the GUI difftool:
$ git pr show -t 4006

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4006.diff

…or should not contain suggestion to submit a bug report
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented May 13, 2021

👋 Welcome back dholmes! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

@openjdk openjdk bot commented May 13, 2021

@dholmes-ora The following label will be automatically applied to this pull request:

  • hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the hotspot label May 13, 2021
@dholmes-ora
Copy link
Member Author

@dholmes-ora dholmes-ora commented May 13, 2021

/label remove hotspot
/label add hotspot-runtime

@openjdk openjdk bot removed the hotspot label May 13, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 13, 2021

@dholmes-ora
The hotspot label was successfully removed.

@openjdk openjdk bot added the hotspot-runtime label May 13, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 13, 2021

@dholmes-ora
The hotspot-runtime label was successfully added.

@dholmes-ora dholmes-ora marked this pull request as ready for review May 13, 2021
@openjdk openjdk bot added the rfr label May 13, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 13, 2021

Webrevs

Copy link
Member

@tstuefe tstuefe left a comment

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have attempted to so so multiple times, but the patches ballooned. I may try again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp Outdated Show resolved Hide resolved
src/hotspot/share/utilities/debug.cpp Outdated Show resolved Hide resolved
src/hotspot/share/utilities/debug.hpp Outdated Show resolved Hide resolved
src/hotspot/share/utilities/debug.hpp Show resolved Hide resolved
Copy link
Member

@tstuefe tstuefe left a comment

All good.

@openjdk
Copy link

@openjdk openjdk bot commented May 13, 2021

@dholmes-ora This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report

Reviewed-by: stuefe, kevinw, gziemski

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 87 new commits pushed to the master branch:

  • cf97252: 8264561: javap get NegativeArraySizeException on bad instruction
  • b8856b1: 8263614: javac allows local variables to be accessed from a static context
  • ea36836: 8267236: Versioned platform link in TestMemberSummary.java
  • d5a15f7: 8263438: Unused method AbstractMemberWriter.isInherited
  • dd5a84c: 8267162: Add jtreg test group definitions for langtools
  • 39a454b: 8260331: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "ERROR: icon and imageIcon not same."
  • a29612e: 8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException
  • a555fd8: 8264734: Some SA classes could use better hashCode() implementation
  • 2313a21: 8266637: CHT: Add insert_and_get method
  • 7b736ec: 8266489: Enable G1 to use large pages on Windows when region size is larger than 2m
  • ... and 77 more: https://git.openjdk.java.net/jdk/compare/18e9d28e8af02650ba30e4816404df48b1062162...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label May 13, 2021
@kevinjwalls
Copy link

@kevinjwalls kevinjwalls commented May 14, 2021

Hi David, looks good.

I get it now I've found that should_report_bug() really means "is vm internal error". Literally, "is this NOT a native memory allocation failure".

If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.)

@tstuefe
Copy link
Member

@tstuefe tstuefe commented May 14, 2021

Hi Kevin,

If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.)

My preference would be to keep the patches as concise as possible, because that makes backporting patches easier. vmError is overdue for some cleanups, but I'd prefer those concentrated in a cleanup RFE, which would give us just one commit to packport, instead of spreading cleanups over unrelated patches.

Just my 5c, David may see this differently.

Cheers, Thomas

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 14, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

Hi Thomas,

Thanks for looking at this.

On 13/05/2021 3:51 pm, Thomas Stuefe wrote:

On Thu, 13 May 2021 02:14:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that.

Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have attempted to so so multiple times, but the patches ballooned. I may try again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp line 294:

292: void report_fatal_impl(VMErrorType error_type, const char* file, int line,
293: const char* detail_fmt, va_list detail_args)
294: ATTRIBUTE_PRINTF(4,0);

Can prototype and implementation be merged while retaining the attrib marker?

Unfortunately no, that is why they are both present and commented.

src/hotspot/share/utilities/debug.cpp line 298:

296: // Definition
297: void report_fatal_impl(VMErrorType error_type, const char* file, int line,
298: const char* detail_fmt, va_list detail_args) {

Can this function be static? Any reason to expose it?

No reason to expose. Changed to static.

src/hotspot/share/utilities/debug.hpp line 154:

152: OOM_MMAP_ERROR = 0xe0000002,
153: OOM_MPROTECT_ERROR = 0xe0000003,
154: OOM_JAVA_HEAP_FATAL = 0xe000004

Add one more zero? To keep it in line with the other errors?

Ooops! Well spotted. I've no idea why these are expressed this way
though and not just 0, 1, 2, 3, 4.

src/hotspot/share/utilities/debug.hpp line 168:

166: int status, const char* detail);
167: void report_fatal(const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4);
168: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);

See above, can we not expose this?

?? These are the ones that are meant to be exposed. We hide behind the
fatal() macro for the first case but these are the exported API.

Thanks,
David

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 14, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

Hi Thomas,

Thanks for looking at this.

On 13/05/2021 3:51 pm, Thomas Stuefe wrote:

On Thu, 13 May 2021 02:14:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that.

Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have attempted to so so multiple times, but the patches ballooned. I may try again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp line 294:

292: void report_fatal_impl(VMErrorType error_type, const char* file, int line,
293: const char* detail_fmt, va_list detail_args)
294: ATTRIBUTE_PRINTF(4,0);

Can prototype and implementation be merged while retaining the attrib marker?

Unfortunately no, that is why they are both present and commented.

src/hotspot/share/utilities/debug.cpp line 298:

296: // Definition
297: void report_fatal_impl(VMErrorType error_type, const char* file, int line,
298: const char* detail_fmt, va_list detail_args) {

Can this function be static? Any reason to expose it?

No reason to expose. Changed to static.

src/hotspot/share/utilities/debug.hpp line 154:

152: OOM_MMAP_ERROR = 0xe0000002,
153: OOM_MPROTECT_ERROR = 0xe0000003,
154: OOM_JAVA_HEAP_FATAL = 0xe000004

Add one more zero? To keep it in line with the other errors?

Ooops! Well spotted. I've no idea why these are expressed this way
though and not just 0, 1, 2, 3, 4.

src/hotspot/share/utilities/debug.hpp line 168:

166: int status, const char* detail);
167: void report_fatal(const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4);
168: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);

See above, can we not expose this?

?? These are the ones that are meant to be exposed. We hide behind the
fatal() macro for the first case but these are the exported API.

Thanks,
David

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 14, 2021

Mailing list message from Thomas Stüfe on hotspot-runtime-dev:

Hi David,

On Thu, May 13, 2021 at 10:04 AM David Holmes <david.holmes at oracle.com>
wrote:

Hi Thomas,

Thanks for looking at this.

On 13/05/2021 3:51 pm, Thomas Stuefe wrote:

On Thu, 13 May 2021 02:14:43 GMT, David Holmes <dholmes at openjdk.org>
wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate
we've requested a Java OOM error to be fatal. A new overload of
report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that
encompasses more than just printing the bug submission URL, so I added a
new specific check for that.

Checked hs_err files before and after with the fix, from the
CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have
attempted to so so multiple times, but the patches ballooned. I may try
again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp line 294:

292: void report_fatal_impl(VMErrorType error_type, const char* file,
int line,
293: const char* detail_fmt, va_list detail_args)
294: ATTRIBUTE_PRINTF(4,0);

Can prototype and implementation be merged while retaining the attrib
marker?

Unfortunately no, that is why they are both present and commented.

src/hotspot/share/utilities/debug.cpp line 298:

296: // Definition
297: void report_fatal_impl(VMErrorType error_type, const char* file,
int line,
298: const char* detail_fmt, va_list
detail_args) {

Can this function be static? Any reason to expose it?

No reason to expose. Changed to static.

src/hotspot/share/utilities/debug.hpp line 154:

152: OOM_MMAP_ERROR = 0xe0000002,
153: OOM_MPROTECT_ERROR = 0xe0000003,
154: OOM_JAVA_HEAP_FATAL = 0xe000004

Add one more zero? To keep it in line with the other errors?

Ooops! Well spotted. I've no idea why these are expressed this way
though and not just 0, 1, 2, 3, 4.

This enum, signal numbers (posix) and windows SEH codes are mashed together
in VMError::_id. I guess this is some effort to make sure value ranges for
these three semantically different things don't intersect.

I don't like this design though. I would like to keep these as two separate
things: at the highest lvl, differentiate between internal fatal errors and
crashes. For each type keep detail info: For crashes,
signal number+context+siginfo. For asserts, error type and maybe context.

src/hotspot/share/utilities/debug.hpp line 168:

166: int status, const char* detail);
167: void report_fatal(const char* file, int line, const char*
detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4);
168: void report_fatal(VMErrorType error_type, const char* file, int
line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);

See above, can we not expose this?

?? These are the ones that are meant to be exposed. We hide behind the
fatal() macro for the first case but these are the exported API.

Yes, but atm the sole user of this api lives in debug.cpp. Otherwise this
API is only exposed via the specialized report_java_out_of_memory().

Never mind though, it is not that important.

Thanks,
David

Patch looks good to me.

Cheers, Thomas

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 14, 2021

Mailing list message from Thomas Stüfe on hotspot-runtime-dev:

Hi David,

On Thu, May 13, 2021 at 10:04 AM David Holmes <david.holmes at oracle.com>
wrote:

Hi Thomas,

Thanks for looking at this.

On 13/05/2021 3:51 pm, Thomas Stuefe wrote:

On Thu, 13 May 2021 02:14:43 GMT, David Holmes <dholmes at openjdk.org>
wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate
we've requested a Java OOM error to be fatal. A new overload of
report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that
encompasses more than just printing the bug submission URL, so I added a
new specific check for that.

Checked hs_err files before and after with the fix, from the
CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

Hi David,

mostly fine, minor nits.

Side note, I really would like to clean up this coding a bit. I have
attempted to so so multiple times, but the patches ballooned. I may try
again, maybe in tiny baby steps.

Cheers, Thomas

src/hotspot/share/utilities/debug.cpp line 294:

292: void report_fatal_impl(VMErrorType error_type, const char* file,
int line,
293: const char* detail_fmt, va_list detail_args)
294: ATTRIBUTE_PRINTF(4,0);

Can prototype and implementation be merged while retaining the attrib
marker?

Unfortunately no, that is why they are both present and commented.

src/hotspot/share/utilities/debug.cpp line 298:

296: // Definition
297: void report_fatal_impl(VMErrorType error_type, const char* file,
int line,
298: const char* detail_fmt, va_list
detail_args) {

Can this function be static? Any reason to expose it?

No reason to expose. Changed to static.

src/hotspot/share/utilities/debug.hpp line 154:

152: OOM_MMAP_ERROR = 0xe0000002,
153: OOM_MPROTECT_ERROR = 0xe0000003,
154: OOM_JAVA_HEAP_FATAL = 0xe000004

Add one more zero? To keep it in line with the other errors?

Ooops! Well spotted. I've no idea why these are expressed this way
though and not just 0, 1, 2, 3, 4.

This enum, signal numbers (posix) and windows SEH codes are mashed together
in VMError::_id. I guess this is some effort to make sure value ranges for
these three semantically different things don't intersect.

I don't like this design though. I would like to keep these as two separate
things: at the highest lvl, differentiate between internal fatal errors and
crashes. For each type keep detail info: For crashes,
signal number+context+siginfo. For asserts, error type and maybe context.

src/hotspot/share/utilities/debug.hpp line 168:

166: int status, const char* detail);
167: void report_fatal(const char* file, int line, const char*
detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4);
168: void report_fatal(VMErrorType error_type, const char* file, int
line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);

See above, can we not expose this?

?? These are the ones that are meant to be exposed. We hide behind the
fatal() macro for the first case but these are the exported API.

Yes, but atm the sole user of this api lives in debug.cpp. Otherwise this
API is only exposed via the specialized report_java_out_of_memory().

Never mind though, it is not that important.

Thanks,
David

Patch looks good to me.

Cheers, Thomas

void report_fatal(const char* file, int line, const char* detail_fmt, ...) {
va_list detail_args;
va_start(detail_args, detail_fmt);
report_fatal_impl(INTERNAL_ERROR, file, line, detail_fmt, detail_args);
va_end(detail_args);
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need this API? Can't we just update:

#define fatal(...)                                                                \
do {                                                                              \
  TOUCH_ASSERT_POISON;                                                            \
  report_fatal(INTERNAL_ERROR, __FILE__, __LINE__, __VA_ARGS__);                                  \
  BREAKPOINT;                                                                     \
} while (0)

Copy link
Member Author

@dholmes-ora dholmes-ora May 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the fatal() macro seems to be the only user of the existing report_fatal then yes I think we can simplify this as you suggest. I had thought it was used directly from elsewhere.

Thanks for the suggestion.

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 17, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

Hi Kevin,

Thanks for looking at this.

On 14/05/2021 8:18 pm, Kevin Walls wrote:

On Thu, 13 May 2021 08:06:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through.

VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that.

Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test.

Tested tiers 1-3 for good measure.

Thanks,
David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

Review comments from Thomas

Marked as reviewed by kevinw (Committer).

Hi David, looks good.

I get it now I've found that should_report_bug() really means "is vm internal error". Literally, "is this NOT a native memory allocation failure".

If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.)

I couldn't determine exactly what "should_report_error" was really
trying to distinguish, beyond the obvious case of "report the bug submit
URL". As Thomas notes there is potential for more rework in this area,
but I don't want to increase the scope of the current change.

Thanks,
David

@tstuefe
Copy link
Member

@tstuefe tstuefe commented May 17, 2021

Looks still good.

..Thomas

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 17, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

Thanks Thomas!

David

On 17/05/2021 3:44 pm, Thomas Stuefe wrote:

Copy link

@gerard-ziemski gerard-ziemski left a comment

Looks good, thanks!

@dholmes-ora
Copy link
Member Author

@dholmes-ora dholmes-ora commented May 17, 2021

Thanks Gerard!

@dholmes-ora
Copy link
Member Author

@dholmes-ora dholmes-ora commented May 17, 2021

/integrate

@openjdk openjdk bot closed this May 17, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels May 17, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 17, 2021

@dholmes-ora Since your change was applied there have been 92 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

Pushed as commit cd1c17c.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@dholmes-ora dholmes-ora deleted the 8266404 branch May 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime integrated
4 participants