On Fri, 29 Aug 2025 06:54:13 GMT, Leonid Mesnik <[email protected]> wrote:

>> But we are only in this method because the Java method has completed 
>> normally so there cannot be a pending exception at this point. ???
>
> There is might be exception if current method has been called after exception 
> has been thrown. It is quite rare case, but I've seem when add 
> `assert(!exception_exit, "")`. It might happens if exception thrown  and 
> there were other upcals  in the same thread before exception has been caught. 
> I think I've seen it during classloading or some method bootstrapping.
> 
> The test `TestMethodExitWithPendingException`  simulates the same issue by 
> calling method in the MethodExit event call back.
> For method `upCall` the `exception_exit` would be true, because the method is 
> called while exception is pending. However, the method `upCall` exits 
> normally and is not unwinded. So this method `post_method_exit` is called.
> 
> Here is the example of such stack in the on of the tests were assertion has 
> been hit. The VM tries to load classes when exception is throwing.
> 
> V  [libjvm.so+0x1415d6c]  JvmtiExport::post_method_exit(JavaThread*, Method*, 
> frame)+0x29c  (jvmtiExport.cpp:1847)
> V  [libjvm.so+0x1066b86]  
> InterpreterRuntime::post_method_exit(JavaThread*)+0xe6  
> (interpreterRuntime.cpp:1278)
> j  java.lang.Object.<init>()V+0 java.base@26-internal
> j  java.lang.Throwable.<init>(Ljava/lang/String;)V+1 java.base@26-internal
> j  java.lang.Error.<init>(Ljava/lang/String;)V+2 java.base@26-internal
> j  java.lang.LinkageError.<init>(Ljava/lang/String;)V+2 java.base@26-internal
> j  java.lang.NoClassDefFoundError.<init>(Ljava/lang/String;)V+2 
> java.base@26-internal
> v  ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd
> V  [libjvm.so+0x1089117]  JavaCalls::call_helper(JavaValue*, methodHandle 
> const&, JavaCallArguments*, JavaThread*)+0x4f7  (javaCalls.cpp:415)
> V  [libjvm.so+0x108ab3f]  JavaCalls::call_special(JavaValue*, Klass*, 
> Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x18f  (javaCalls.cpp:323)
> V  [libjvm.so+0x108b3c6]  JavaCalls::construct_new_instance(InstanceKlass*, 
> Symbol*, JavaCallArguments*, JavaThread*)+0x116  (javaCalls.cpp:289)
> V  [libjvm.so+0xd74f4b]  Exceptions::new_exception(JavaThread*, Symbol*, 
> Symbol*, JavaCallArguments*, Handle)+0x1db  (exceptions.cpp:320)
> V  [libjvm.so+0xd7517f]  Exceptions::new_exception(JavaThread*, Symbol*, 
> Symbol*, JavaCallArguments*, Handle, Handle)+0x2f  (exceptions.cpp:341)
> V  [libjvm.so+0xd7609f]  Exceptions::new_exception(JavaThread*, Symbol*, char 
> const*, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x3bf  
> (exceptions.cpp:424)
> V  [libjvm.so+0xd7b9a0]  Exceptions::_throw_msg_cause(JavaThread*, char 
> const*, int, Symbol*, char co...

Sorry I still can't see this. Method A throws an exception. The callback for 
the method-exit event for method A then invokes Java method B. Method B also 
has a callback enabled and so we are processing the method-exit for B. Method B 
has completed normally, but the exception from method A is still listed as 
pending? I can't see how that would come about as we must (temporarily) clear 
the pending exception to do the upcall else the upcall method would immediately 
throw that pending exception. But if we have cleared it then the upcall 
method's method-exit event shouldn't be able to see it. Similarly we must 
save/restore the JvmtiThreadState else we would be processing the normal exit 
as if it were an exception one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2312899717

Reply via email to