RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Oct 31 16:53:06 PDT 2013


Good.

Thanks,
Vladimir

On 10/31/13 4:09 PM, Mikael Vidstedt wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8026775
> webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.01/webrev/
>
> Exec summary:
>
> The stack banging code in the UncommonTrapBlob is not pre-touching all
> the stack shadow pages as it should. The result is that under some
> circumstances it may leave unmapped "holes" on the stack, and when a
> compiled method later touches a stack page on the other side of the hole
> Windows will raise an exception because it requires all stack pages to
> be touched/mapped in order.
>
>
> Details:
>
> The code in MacroAssembler::bang_stack_size() is supposed to generate
> code which touches enough stack pages to make room for the interpreter
> frame for the deoptimized method and then touch an additional
> StackShadowPages pages. However, the code fails to do this because:
>
> a) it touches the same page twice (the last page touched in the first
> loop is the exact same address touched the first time in the second
> loop), and
> b) it doesn't loop all the way up to *and including* StackShadowPages
> (the "-1" is incorrect, and so is the less than)
>
> The corresponding code in
> AbstractInterpreterGenerator::bang_stack_shadow_pages() touches all
> pages from 1 page below sp all the way down to StackShadowPages below sp
> *inclusive*. The UncommonTrapBlob is supposed to mimic that exact same
> behavior.
>
> Cheers,
> Mikael
>


More information about the hotspot-compiler-dev mailing list