RFR(xxs): 8205925: Print correct and more information about secondary errors.

[Thomas Stüfe]

Hi Coleen,

No allocation beside that 64 Byte stack array, and that only because of the
ridiculous long windows exception names..

No 11 though, really? I thought the ramp down starts tomorrow at 1500 ?
Sigh..

Thanks, Tomas

On Wed 27. Jun 2018 at 20:05, <coleen.phillimore at oracle.com> wrote:

>
> This seems fine to me as a small change.  No more for JDK 11 though!
>  From what I can tell, this does not allocate (malloc or resource area)
> any memory, true?
>
> thanks,
> Coleen
>
> On 6/27/18 2:00 PM, Thomas Stüfe wrote:
> > (Submit Tests came back clean)
> >
> > On Wed 27. Jun 2018 at 18:18, Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
> >
> >> Hi all,
> >>
> >> could I ask you for reviews for this small improvement:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8205925
> >>
> >>
> http://cr.openjdk.java.net/~stuefe/webrevs/8205925-print-info-on-secondary-errors-in-error-handling/webrev.00/webrev/
> >>
> >> Daniel, when solving JDK-8205648, remarked on the lack of error
> >> information for secondary errors, i.e. errors which occur during error
> >> handling.
> >>
> >> Currently we see:
> >>
> >> [error occurred during error reporting (test secondary crash 1), id 0xb]
> >>
> >> Which does not tell much, especially since the printed id is wrong, it
> >> is the id of the primary error, not the secondary one. It would be
> >> helpful to see actually what error occurred during error reporting.
> >>
> >> This patch adds the ability to see the correct secondary error.
> >>
> >> Looks like this, for secondary signals:
> >>
> >> [error occurred during error reporting (test secondary crash 1), id
> >> 0x8, SIGSEGV (0xb) at pc=0x00007fb877815ca6]
> >>
> >> and for secondary asserts:
> >>
> >> [error occurred during error reporting (test secondary crash 1), id
> >> 0xe0000000, Internal Error
> >>
> >>
> (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/utilities/vmError.cpp:1726)]
> >>
> >> --
> >>
> >> Implementation note: when printing information about the secondary
> >> error, I follow closely the already existing STEP("printing
> >> exception/signal name"). I avoided any unnecessary refactoring since I
> >> wanted to get this thru the door before 11 closes. Note that
> >> https://bugs.openjdk.java.net/browse/JDK-8196507 also touches these
> >> areas and under that bug I have some cleanups for 12 planned.
> >>
> >> Thanks & Regards, Thomas
> >>
>
>