RFR(xxs): 8176140: Crashes or timeouts during error reporting may lead to infinitely repeated error logs until ErrorLogTimeout is hit
Thomas Stüfe
thomas.stuefe at gmail.com
Thu Mar 9 08:13:24 UTC 2017
Thank you guys. Will need a sponsor.
Kind Regards, Thomas
On Thu, Mar 9, 2017 at 3:57 AM, Chris Plummer <chris.plummer at oracle.com>
wrote:
> On 3/8/17 6:27 PM, David Holmes wrote:
>
>> Hi Thomas,
>>
>> On 9/03/2017 4:38 AM, Thomas Stüfe wrote:
>>
>>> Hi all,
>>>
>>> please review this tiny fix.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8176140
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8176140-Crashes-
>>> or-timeouts-during-error-reporting-may-lead-to-infinite
>>> ly-repeated-error-logs-until-ErrorLogTimeout-is-hit/jdk10-
>>> webrev.00/webrev/
>>>
>>> Basically, the error reporting had this bug where a secondary crash (or,
>>> after JDK-8166944, a timeout) could lead to an error log with infinitely
>>> repeated content. In practice, one would hit either the maximum stack
>>> depth
>>> of the reporting thread or the ErrorLogTimeout.
>>>
>>> This would happen if the crash were to happen inside
>>> VMError::report_and_die(), after the reporting is done
>>> |VMError::report(&log, true)| and before the |log_done| flag is set. This
>>> is a very small window, but Chris was able to trigger this bug by
>>> introducing an error inside an ubiquitous base function (malloc), so it
>>> is
>>> not just theoretical.
>>>
>>> The fix is simply to set log_done right after the VMError::report() call.
>>>
>>
>> Seems reasonable.
>>
> +1. Thanks for fixing.
>
> Chris
>
>
>> Thanks,
>> David
>> -----
>>
>> Thanks & Kind Regards, Thomas
>>>
>>>
>
>
More information about the hotspot-runtime-dev
mailing list