RFR[13, xs]: 8227275: Within native OOM error handling, assertions may hang the process

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Jul 10 13:02:39 UTC 2019



On 7/10/19 1:38 AM, Thomas Stüfe wrote:
>
> Hi Coleen,
>
> thanks for looking at it! Remarks below.
>
> On Tue, Jul 9, 2019 at 11:12 PM <coleen.phillimore at oracle.com 
> <mailto:coleen.phillimore at oracle.com>> wrote:
>
>
>     http://cr.openjdk.java.net/~stuefe/webrevs/8227275-native-oom-hanging-assertions/webrev.00/webrev/src/hotspot/share/utilities/debug.cpp.udiff.html
>
>     I don't understand why you don't just leave the poison page PROT_NONE
>     and call this from handle_assert_poison_fault?
>
>     +void disarm_assert_poison() {
>     + g_assert_poison = &g_dummy;
>     +}
>     +
>
>     Then you don't have to check that it succeeded.   At this point, it
>     doesn't matter.
>
>
> Because unfortunately that does not work. At the point it is too late.
>
> handle_assert_poison_fault() is called from the signal handler to 
> handle a poison touch SIGSEGV. When it is handled, it will return to 
> the caller - jumps back to the instruction triggering the SEGV. There, 
> poison page address is already loaded into a register and cannot be 
> changed.

Oh, I see.  Thank you for the explanation.  Looks good to me then.

Coleen

>
> The only other choice we have, beside removing the write protection 
> from the poison page, is not to return to the caller. That is what 
> happens when I return false from handle_assert_poison_fault(). In that 
> case the signal handler proceeds as if this were a real SEGV.
>
> Cheers, Thomas
>
>
>     Coleen
>
>     On 7/9/19 5:23 AM, Thomas Stüfe wrote:
>     > Dear all,
>     >
>     > may I please have reviews for the following issue:
>     >
>     > JBS: https://bugs.openjdk.java.net/browse/JDK-8227275
>     > cr:
>     >
>     http://cr.openjdk.java.net/~stuefe/webrevs/8227275-native-oom-hanging-assertions/webrev.00/webrev/
>     >
>     > Summary: on OOM, we may fail to disarm assertion poison page;
>     this may lead
>     > to endless loops during error handling if assertions happen in
>     native OOM
>     > scenarios.
>     >
>     > For more details, pls see the JBS issue.
>     >
>     > Thanks, Thomas
>



More information about the hotspot-runtime-dev mailing list