RFR: 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION

[Daniel D.Daugherty]

On Mon, 15 Mar 2021 11:48:38 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> When returning from the last Java frame back to vm and hitting a safepoint poll on that last return we sometimes have a last java frame but no vframe.
> This seem to be a bug in itself, handled in: 8263576
> 
> Other places which uses vframe NULL checks it before, so let's do that in GetCurrentLocationClosure also.
> 
> Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.

Thumbs up!

I agree that the code should have checked for "if (vf != NULL) {"
instead of asserting that "(vf != NULL)".

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 263:

> 261:     // There can be a race condition between a handshake
> 262:     // and the target thread exiting from Java execution.
> 263:     // We must recheck the last Java frame still exists.

Typo: s/recheck the last/recheck that the last/
(not your typo, but since you're in there...)

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 266:

> 264:     if (!jt->is_exiting() && jt->has_last_Java_frame()) {
> 265:       javaVFrame* vf = jt->last_java_vframe(&rm);
> 266:       assert(vf != NULL, "must have last java frame");

The code before we converted to handshakes also had this assert.

The pre-handshake code did the work in the doit() function for the
VM_GetCurrentLocation VM-op. This makes me wonder if we always
had frames here when this was previously done via VM-op? And that
makes me wonder whether handshakes is doing something different
so we don't always have a frame here?

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3010