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

[Chris Plummer]

On Tue, 30 Jul 2024 23:13:23 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

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

> 356: 
> 357:     // Block VMDeath event and other ClassPrepare events while this callback is executed.
> 358:     // Sync with VMDeath event guards agains JVMTI_ERROR WRONG_PHASE.

Suggestion:

    // Sync with VMDeath event guards agains JVMTI_ERROR_WRONG_PHASE.

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

> 357:     // Block VMDeath event and other ClassPrepare events while this callback is executed.
> 358:     // Sync with VMDeath event guards agains JVMTI_ERROR WRONG_PHASE.
> 359:     err = (*jvmti)->RawMonitorEnter(jvmti, event_mon);

I don't see how this fixes the problem. You can be exiting VMDeath when this monitor is entered. This does not block the get_thread_local() call below, which is what leads to the WRONG_PHASE. I think using a raw monitor is the right approach, but I was expecting to see VMDeath set a flag after grabbing the monitor that indicated VMDeath had been called. Then ClassPrepare should check this flag after grabbing the monitor and ignore the event if it is set.

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

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