On Sat, 27 Jul 2024 01:55:23 GMT, Chris Plummer <cjplum...@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.
The test is testing to make sure a jdb deferred breakpoint on an inner class
works. The breakpoint line number information for the debuggee is wrong, so the
test should be failing, but isn't. The debugger side has:
static final String DEBUGGEE_LOCATION1 = DEBUGGEE_CLASS +
"$Nested$DeeperNested$DeepestNested:43";
static final String DEBUGGEE_LOCATION2 = DEBUGGEE_CLASS +
"$Inner$MoreInner:57";
And the debuggee side has:
flag = input; /* <-------- This is line number 43 */
and
content += input; /* <-------- This is line number 57 */
However line numbers (even the ones in the comments) are wrong. They probably
have been ever since this file was open sourced and the new copyright header
was added. As a result, in the jdb out you see failures like:
[17:24:22.782] reply[0]: > Unable to set deferred breakpoint
nsk.jdb.stop_at.stop_at002.stop_at002a$Nested$DeeperNested$DeepestNested:43 :
No code at line 43 in
nsk.jdb.stop_at.stop_at002.stop_at002a$Nested$DeeperNested$DeepestNested
However, this is not caught by the test. The test only checks for the failed
setting of the deferred breakpoint when executing the jdb "stop at" command.
The failure does not actually happen until after the test continues, allowing
the class to be loaded and for jdb to actually attempt to set the breakpoint.
So there are two issues with the test: wrong breakpoint line number
information, and failure to determine that a deferred breakpoint failed to be
setup when the class was loaded.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20366#issuecomment-2253705631
