On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are >> used to query the hotspot about diagnostic commands. They provide output >> arrays for the information: >> >> >> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, >> jstring command, dcmdArgInfo* infoArray) >> >> >> but array size is implicitly assumed to be known to both caller and callee. >> Caller and callee negotiate those sizes in prior steps, but things can go >> wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off >> - did not reflect the real number of its jcmd parameters - which led to a >> hidden memory overwriter. >> >> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this >> particular issue (The VM I analyzed was older). Still, it would be good if >> we had additional safety measures here. >> >> ------------- >> >> Testing: >> - manual tests with artificially induced error in one dcmd for debug, release >> - GHAs (which include tier1 serviceability jcmd tests which use JMX and >> exercise these APIs) > > Thomas Stuefe has updated the pull request incrementally with one additional > commit since the last revision: > > Remove changes to GetDiagnosticCommandInfo Just out of curiosity, for such changes, should we in principle bump `JMM_VERSION`? Or do we not care because libjvm and libmanagement are always shipped together? ------------- PR: https://git.openjdk.java.net/jdk/pull/6363
