On Thu, 5 Feb 2026 11:13:45 GMT, Johan Sjölen <[email protected]> wrote:
>> @sspitsyn I am not sure to follow your comment.
>> In the case of invalid structure, no exception was pending and therefore the
>> method `load_new_class_versions` returns no error.
>> if `merge_cp_and_rewrite` returns anything else than `JVMTI_ERROR_NONE` it
>> should be propagated.
>> Now, if you want to process pending exception first I can move the check
>> result after, but for example the call above to
>> `compare_and_normalize_class_versions` is done like this also
>
> Hi @jpbempel, I couldn't see the equivalent form in `c_a_n_c_v` (returning
> early when there may be a pending exception).
>
>> if merge_cp_and_rewrite returns anything else than JVMTI_ERROR_NONE it
>> should be propagated.
>
> Yeah, but you've got a `THREAD` call into a method taking `TRAPS` as an
> argument. A method taking `TRAPS` can be seen as one being able to throw, but
> we're doing the stack unwinding manually in the JVM.
>
> As an example, in the code for `merge_cp_and_rewrite` the call to
> `ConstantPool::allocate` can set a pending exception. You can see this if you
> dig down into `MetadataFactory` and so on, look at `metaspace.cpp:33` and
> see the pending exception there.
>
> So, by returning early, you're not handling the pending exception, which
> breaks the JVM.
It basically seems like the correct fix is:
if (HAS_PENDING_EXCEPTION) {
// ... same as before
} else if (res != JVMTI_ERROR_NONE) {
return res;
}
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2768503935
