RFR: 8337299: vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java failure goes undetected

Chris Plummer cjplummer at openjdk.org
Thu Aug 1 17:01:35 UTC 2024


On Wed, 31 Jul 2024 07:51:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test is setting breakpoints on the wrong line numbers, which causes setting up the breakpoint to fail, but the test also has buggy error checking, so the test doesn't detect the failures and still passes. I fixed the breakpoint line numbers and the error checking. More details in the first comment.
>> 
>> Testing tbd: I'll run the tier5 svc testing, which includes this test suite.
>
> test/hotspot/jtreg/vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java line 147:
> 
>> 145:         }
>> 146: 
>> 147:         found = grep.findFirst("Breakpoint hit: \"thread=main\", ");
> 
> Q: Is it possible to check for the exact breakpoint location here?

The problem is in the test we have:

`    static final String DEBUGGEE_LOCATION2 = DEBUGGEE_CLASS + "$Inner$MoreInner:78";`

And the jdb output is:

`reply[2]: Breakpoint hit: "thread=main", nsk.jdb.stop_at.stop_at002.stop_at002a$Inner$MoreInner.foo(), line=78 bci=0`

So I can't just search for DEBUGGEE_LOCATION2 in the output. I could do further factoring of DEBUGGEE_LOCATION2 so it is easier to construct a search pattern that would work, but I don't feel it is worth it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20366#discussion_r1700519455


More information about the serviceability-dev mailing list