JDK-8134434 : JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-08-25
  • Updated: 2017-05-19
  • Resolved: 2016-07-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b131Fixed
Related Reports
Relates :  
Relates :  
Description
Reported via e-mail:

On 8/11/15 9:06 AM, Reingruber, Richard wrote:
> Hi,
>
> I would like to report that the assertion
>
>     assert(_exception_caught == false) failed: _exception_caught is out of phase
>
> at jvmtiThreadState.hpp:170 fires when running the command
>
>     ./images/jdk/bin/java -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n -Xbatch ExceptionCaughtOutOfPhaseAssertion
>
> (when analyzing you might want to add -XX:-TieredCompilation -XX:-Inline '-XX:CompileCommand=compileonly *::run')
>
> Source Code:
>
>     import java.security.AccessController;
>     import java.security.PrivilegedAction;
>         public class ExceptionCaughtOutOfPhaseAssertion {
>             public static void main(String[] args) {
>             PrivilegedAction action = new HotThrowingAction();
>             System.out.println("### Warm-up");
>             for(int i=0; i<11000; i++) {
>                 try {
>                     action.run(); // call run() to get it compiled
>                 } catch(Throwable t) { /* ignored */ }
>             }
>             System.out.println("### Warm-up done");
>             System.out.println("### Executing privileged action");
>             AccessController.doPrivileged(action);
>         }
>                 public static class HotThrowingAction implements PrivilegedAction {
>             public Object run() {
>                 throw new Error();
>             }
>         }
>     }
>     My Analysis:
>
> * Error is thrown in interpreted activation of run()
>    - JvmtiThreadState::_exception_detected is set to true
>    - JvmtiThreadState::_exception_caught   is set to false
> * Error is caught in main() method
>    - JvmtiThreadState::_exception_detected is set to false
>    - JvmtiThreadState::_exception_caught   is set to true
> * run() method is compiled
> * PrivilegedAction is executed
> * compiled activation of run() method
>    - Error object is allocated and initialized
>    - JavaThread::_should_post_on_exceptions_flag is checked and found to be false
>      -> *no* uncommon trap
>    - compiled frame is popped, rethrow stub calls OptoRuntime::rethrow_C()
>    - _exception_detected is *not* set, remains false
>    - _exception_caught is still true
> * Java call in JVM_DoPrivileged() returns with pending exception
> * CLEAR_PENDING_EXCEPTION triggers the assertion
>
> How to Fix? I'm not really an expert in this area, but here are my two cent:
>
> (a) Improve the assertion ...but how?! Toggling JVMTI exception notifications does not seem
>      to be synchronized with java execution.
>
> (b) Calling JvmtiExport::post_exception_throw() in OptoRuntime::rethrow_C() is probably not possible,
>      because of the JRT_LEAF comment for rethrow_C(), but _exception_detected = true could be set.
>
> (c) Remove the assertion.
>
> I guess (b) could be acceptable.
>
> What do you think?
>
> Best regards,
> Richard. 
Comments
It seems the fix of JDK-6972759 is a probably root cause of this bug.
21-10-2016

Original mail thread. http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019613.html
06-07-2016

I am able to run the testcase and see the assert.
28-03-2016

ILW = M (JVM crash only in debug builds and certain platforms) H (always reproducible) H (no workaround) = P2
01-09-2015

And more info: On 8/12/15 2:30 AM, Richard Reingruber wrote: > Sorry, forgot to add a stack trace. This is amd64: > > Stack: [0x00007fe6cdacc000,0x00007fe6cdbcd000], sp=0x00007fe6cdbc9d30, free space=1015k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xfce6f1] VMError::report(outputStream*)+0x12fd > V [libjvm.so+0xfcfbed] VMError::report_and_die()+0x3fd > V [libjvm.so+0x86b82d] report_vm_error(char const*, int, char const*, char const*)+0xb4 > V [libjvm.so+0xbe44ba] JvmtiThreadState::clear_exception_detected()+0x4e > V [libjvm.so+0xbe3046] JvmtiExport::clear_detected_exception(JavaThread*)+0x72 > V [libjvm.so+0xb50627] JVM_DoPrivileged+0x7e4 > C [libjava.so+0xd04e] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x42 > j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0 > j ExceptionCaughtOutOfPhaseAssertion.main([Ljava/lang/String;)V+59 > v ~StubRoutines::call_stub > [...] > > I can reproduce this on amd64, sparcv9 and ppc64 with dbg builds of the current openjdk9. > > Richard.
25-08-2015