Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9

Christian Thalinger christian.thalinger at oracle.com
Mon Jan 7 14:34:30 PST 2013


On Jan 7, 2013, at 12:30 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:

> Hi,
> 
> Please review the fix for 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9.
> 
> hs24 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/
> jdk8 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/
> 
> The SIGSEGV was caused by an unhandled methodOop in methodOopDesc::fast_exception_handler_bci_for() and JvmtiExport::post_exception_throw(). It's only reproducible on hs24 as oops in the perm-gen could be moved by the GC. The bug was not reported on jdk8. On jdk8, Method* doesn't move. However the fix is still needed on jdk8 since the Method* in JvmtiExport::post_exception_throw() could be redefined after the  methodOopDesc::fast_exception_handler_bci_for() call. The handle will keep it from being deallocated.

I was just going to say it's not required for HS25 but the redefinition is a valid point.  Although imperceptible.  Could we add a comment in:

src/share/vm/oops/method.hpp

to prevent someone undoing this change?

-- Chris

> 
> Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt.
> 
> Thanks,
> Jiangli



More information about the hotspot-runtime-dev mailing list