RFR(xxs): 8144192: [windows] Enhancements to os::print_siginfo()

Thomas Stüfe thomas.stuefe at gmail.com
Tue Dec 1 07:45:53 UTC 2015


Hi David,

ok! Here my new webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8144192-Enhancements-print_siginfo/webrev.01/webrev/
I removed EXCEPTION_GUARD_PAGE from that case. We still print out all
exception details numerically in the else branch, so no information are
lost.

Please also note that I prepared a sister change for review for posix
platforms, 8144219, which moves the special CDS violation handling out of
the os::print_siginfo(). I will fix any merging problems later for whatever
change gets approved last.

Kind Regards, Thomas



On Tue, Dec 1, 2015 at 8:31 AM, David Holmes <david.holmes at oracle.com>
wrote:

> On 30/11/2015 4:52 PM, Thomas Stüfe wrote:
>
>> Hi David,
>>
>> On Mon, Nov 30, 2015 at 6:12 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Thomas,
>>
>>     On 28/11/2015 1:31 AM, Thomas Stüfe wrote:
>>
>>         Hi all,
>>
>>         please take a look at these small enhancements to Windows'
>>         version of
>>         os::print_siginfo.
>>
>>         Bug report: https://bugs.openjdk.java.net/browse/JDK-8144192
>>         Webrev:
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8144192-Enhancements-print_siginfo/webrev.00/webrev/
>>
>>
>>     I couldn't find any documentation to confirm that
>>     EXCEPTION_GUARD_PAGE has the same ExceptionInformation[0] as
>>     EXCEPTION_ACCESS_VIOLATION and EXCEPTION_IN_PAGE_ERROR.
>>
>>
>> That is true. I found this in practice to be true, though. And useful
>> enough to add.
>> But this was some years ago, and since it is undocumented, it may not
>> work anymore. So, if you want, I can remove EXCEPTION_GUARD_PAGE from
>> that case.
>>
>
> Please do. It avoids the potential for introducing anything unexpected.
>
> Thanks,
> David
>
>
> Kind Regards, Thomas
>>
>>     Thanks,
>>     David
>>     -----
>>
>>         Kind regards, Thomas
>>
>>
>>


More information about the hotspot-runtime-dev mailing list