On Fri, 30 Jan 2026 09:07:24 GMT, Jean-Philippe Bempel <[email protected]>
wrote:
>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1477:
>>
>>> 1475: if (res != JVMTI_ERROR_NONE) {
>>> 1476: return res;
>>> 1477: }
>>
>> Pending exception need to be processed and cleared below (see lines:
>> 1478-1487).
>
> @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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2768496944
