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



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