RFR: 8281822: Test failures on non-DTrace builds due to incomplete DTrace* flags handling [v3]
David Holmes
dholmes at openjdk.java.net
Wed Feb 16 07:41:08 UTC 2022
On Wed, 16 Feb 2022 06:12:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>>
>>
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>>
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>>
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>>
>>
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>>
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>>
>> Additional testing:
>> - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>> - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>
> Test fixes
Test change requested - see below.
Also another thought on the fix below.
src/hotspot/share/runtime/arguments.cpp line 2911:
> 2909: } else if (match_option(option, "-XX:+DTraceMethodProbes")) {
> 2910: jio_fprintf(defaultStream::error_stream(),
> 2911: "DTraceMethodProbes flag is not applicable for this configuration\n");
Looking at this again, in light of the test changes, I have to wonder if the pre-existing treatment of `ExtendedDTraceProbes` was wrong and we should simply have used `UNSUPPORTED_OPTION` in these cases?
test/hotspot/jtreg/compiler/runtime/Test8168712.java line 27:
> 25: * @test
> 26: * @requires vm.debug
> 27: * @requires vm.hasDTrace
DTrace is not critical to this test. IIUC the original fix and test had an issue when combined with DTrace hence the test enabled it to check it was fixed by a further patch. So we actually want to run this test regardless. In which case we need to add another test section for when `!vm.hasDTrace` that doesn't pass the DTrace flag.
-------------
Changes requested by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7477
More information about the hotspot-runtime-dev
mailing list