[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RE: assert(_exception_caught == false) failed: _exception_caught is out of phase
From:       "Reingruber, Richard" <richard.reingruber () sap ! com>
Date:       2015-08-26 14:55:56
Message-ID: 7F953F1E7B01F54E9F0B51450984507D39940668 () DEWDFEMB19B ! global ! corp ! sap
[Download RAW message or body]

Hi Daniel,

  > I didn't see any response from the Serviceability Team

Me neither. Thanks for filing a bug for the issue.

Richard.

-----Original Message-----
From: Daniel D. Daugherty [mailto:daniel.daugherty@oracle.com] 
Sent: Dienstag, 25. August 2015 22:12
To: Reingruber, Richard <richard.reingruber@sap.com>
Cc: hotspot-dev@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: Re: assert(_exception_caught == false) failed: _exception_caught is out of phase

Richard,

I didn't see any response from the Serviceability Team, but maybe
I missed it. In any case, I filed:

JDK-8134434 JVM_DoPrivileged() fires assert(_exception_caught == false)
             failed: _exception_caught is out of phase
https://bugs.openjdk.java.net/browse/JDK-8134434

for your issue.

Dan


On 8/12/15 2:36 AM, Richard Reingruber wrote:
>    > Adding serviceability-dev@... since this JVM/TI...
> Thanks Dan.
>
> Sorry, forgot to add a stack trace. This is from 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.
>
>
> On 08/11/2015 08:38 PM, Daniel D. Daugherty wrote:
>> Adding serviceability-dev@... since this JVM/TI...
>>
>> Dan
>>
>>
>> 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.
>>

[prev in list] [next in list] [prev in thread] [next in thread]