RFR: 8335836: serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java fails with unexpected exit code: 112 [v2]

[Chris Plummer]

On Fri, 2 Aug 2024 20:34:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test has been fixed to:
>>  - add a guard against JVMTI_ERROR_WRONG_PHASE
>>  - replace `exit(err)` with `abort()` in the `check_jvmti_error()`
>>  
>> The JVMTI `VMDeath` event is enabled and a `RawMonitor` is introduced to serialize `ClassPrepare` and `VMDeath` events, and so, to prevent JVMTI_ERROR_WRONG_PHASE in the `ClassPrepare` events.
>> 
>> Testing:
>>  - run the test AllowedFunctions.java locally
>>  - TBD: submit a mach5 run for fixed test
>
> Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix typo in a comment
>  - corrections in test ClassPrepare event handler

test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/libAllowedFunctions.c line 363:

> 361:     get_phase(jvmti, &phase);
> 362:     if (phase != JVMTI_PHASE_START && phase != JVMTI_PHASE_LIVE) {
> 363:         if (phase != JVMTI_PHASE_DEAD) {

After this check is made, what prevents JVMTI from moving to the JVMTI_PHASE_DEAD before the get_cur_thread() call below? I'm not sure if the phase is changed to JVMTI_PHASE_DEAD before or after calling VMDeath, but it seems in either case you can end up with the phase changing after making this check. There is nothing that stops the phase from changing while holding the raw monitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20397#discussion_r1702388142