JDK-8185803 : JdbExprTest.sh fails in JDK10-hs nightly due to "Name unknown: java.lang.Long.MAX_VALUE "
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2012
  • CPU: x86_64
  • Submitted: 2017-08-03
  • Updated: 2018-05-30
  • Resolved: 2018-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11 b15Fixed
Related Reports
Relates :  
JDK-8171483 - Revisit com/sun/jdi/JdbMethodExitTest.sh
Sub Tasks
JDK-8185806 :  
Quarantine test JdbExprTest.sh on Windows - Resolved
JDK-8202155 :  
quarantine test com/sun/jdi/JdbExprTest.sh on all platforms - Resolved
Description
The following test failure was spotted in the 2017-08-02 JDK10-hs nightly:

com/sun/jdi/JdbExprTest.sh
    Test failed due to 'Fail: Required output " \\= 9223372036854775807"
    not found in <path>/results/workDir/classes/0/com/sun/jdi/aa3336/jxdbOutput.txt'
    There is also this message: 'com.sun.tools.example.debug.expr.ParseException:
    Name unknown: java.lang.Long.MAX_VALUE' on Win Server 2012 32-bit Server VM.


This part of the log file is bothersome:

Breakpoint hit: "thread=main", JdbExprTest.bkpt(), line=12 bci=0
12           int i = 0;     //@1 breakpoint

main[1] com.sun.tools.example.debug.expr.ParseException: Name unknown: java.lang.Long.MAX_VALUE
 java.lang.Long.MAX_VALUE = null
main[1] 
The application has been disconnected

jdb is up and running enough of the application to hit a breakpoint.
So what would cause the debugger to be unable to resolve
java.lang.Long.MAX_VALUE?
Comments
Yes, this much is known and there was actually a webrev with the fix sent out for review: http://cr.openjdk.java.net/~cjplummer/8185803/webrev.01/ However, I decided to pull the RFR since the test still failed on sparc due to JDK-8171483, so it could not be removed from the problem list. Converting this test to java will fix JDK-8171483, so I decided it was best to also apply the java.lang.Long fix and remove from the problem list at that time. This is all captured a few comments above, but kind of got lost with some discussion that occurred after that.
16-05-2018
Here's a simple tweak that ensures the classes will be loaded by the time the test needs to reference them. diff --git a/test/jdk/com/sun/jdi/JdbExprTest.sh b/test/jdk/com/sun/jdi/JdbExprTest.sh --- a/test/jdk/com/sun/jdi/JdbExprTest.sh +++ b/test/jdk/com/sun/jdi/JdbExprTest.sh @@ -56,6 +56,8 @@ } public static void main(String[] args) { + Long lMax = new Long(Long.MAX_VALUE); + Integer iMax = new Integer(Integer.MAX_VALUE); bkpt(); } }
16-05-2018
"If I ask to inspect a class that is not loaded or initialized I'd probably expect a better error message at least. " We are talking about jdb after all. Not exactly a state-of-art feature rich debugger. The error message seems to come from com/sun/tools/example/debug/expr/lValue.java: lValue.makeName(): throw new ParseException("Name unknown: " + name); Basically no in scope symbol matched the name. This seems to be a fairly generic message for when that happens.
12-05-2018
I'm not sure of the history of failing on Windows, other than it seems to have started when this CR was filed last august, and it was quickly "problem listed" with the @requires to exclude running on Windows. Harold said: "Oddly, this test always fails with Windows JDKs that I built using JPRT (both fastdebug and product) but always passes with Windows JDKs that I built on my laptop. The JDK source for the JPRT builds was the same as the source used to build on my laptop." So there seems to be conditions where it did and did not fail on Windows that are dependent on how it was built. Harold also said: "The test always passes with any JDK (either built by JPRT or built on my laptop) when the JDB commands are entered by hand. " This was not my experience on linux, but maybe before JDK-8198426 introudced the issue on all platforms for some reason you would not see the issue when entering the command by hand. However, I tend to think it may be have been due to differences in how the debugee app was launched. Maybe a JRE vs JDK difference, if that indeed makes a difference, or even the locale. Or maybe launching from within jdb vs as a separate command and then attached to from jdb.
12-05-2018
My 11 test did not include that fix - sorry. But none of that explains why this previously only failed on Windows where I still see it initialized? I guess I'm unsure how the Java debugger is intended to work. If I ask to inspect a class that is not loaded or initialized I'd probably expect a better error message at least.
11-05-2018
With 9 and 10 and older versions of 11, yes, you should see Long being initialized. However, after JDK-8198426 was pushed about 3 weeks ago, you should not see it initialized when running a nop program or with -version: $ build/linux-x64-debug/images/jdk/bin/java -Xlog:"class*" -version | grep -w Long [0.032s][info][class,load] java.lang.Long source: jrt:/java.base java version "11-internal" 2018-09-25 Java(TM) SE Runtime Environment 18.9 (fastdebug build 11-internal+0-2018-05-10-1939549.cplummer.jdk1) Java HotSpot(TM) 64-Bit Server VM 18.9 (fastdebug build 11-internal+0-2018-05-10-1939549.cplummer.jdk1, mixed mode) And here's the output from what is basically a nop program, but with a reference to Long added: $ build/linux-x64-debug/images/jdk/bin/java -Xlog:"class*" Test | grep -w Long [0.032s][info][class,load] java.lang.Long source: jrt:/java.base [0.144s][info][class,init] 368 Initializing 'java/lang/Long' (0x0000000800013808) So I'm not sure why you are seeing it initialized with -version. With regards to the debuggee response when asked to reference an uninitialized class, I would not expect the debuggee to modify the application state, which is what it would do if a print command triggered initialization of a class (running clinits).
11-05-2018
I always see Long being initialized even with just "java -version". That's in 9, 10 and 11. ?? Additionally, if a command like: cmd print java.lang.Long.MAX_VALUE is sent to the debuggee then I would expect the debuggee code to ensure any necessary initialization is done. I would not expect the program being debugged to have to ensure initialization!
11-05-2018
I thought I had this all worked out with the simple test fix, but then a timeout popped up on solaris-sparc. It looks like for the most part the test ran ok, but then at the end of the log you see: --Finish execution with sending "quit" command to JDB --Sending cmd: quit --Quit cmd was sent --waitForFinish: Waiting for mydojdbCmds() to finish And it never returns from this. It seems to be happening quite a lot on solaris-sparc, and looks to be the same issue as JDK-8171483, but with a different test. Since the shell script stability issue will be resolved when the scripts are converted to pure java tests by JDK-8179318, I think it's best to just let this bug be fixed at the same time as JDK-8179318. I was hoping to get the test stable and off the problemlist with this fix, but since that's not 100% attainable, it's not really worth pushing the fix at this time.
11-05-2018
It looks like Long is always loaded, but not initialized. I always see the following, even with nop programs (this is with current JDK sources) $ bin/java -Xlog:"class*" Test | grep -w Long [0.031s][info][class,load] java.lang.Long source: jrt:/java.base However, when I add a reference to Long from within the test program, I see: $ bin/java -Xlog:"class*" Test | grep -w Long [0.031s][info][class,load] java.lang.Long source: jrt:/java.base [0.140s][info][class,init] 368 Initializing 'java/lang/Long' (0x00000007c0013808) This is also what I see if I remove the changeset for this CR. The class needs to be initialized before jdb can reference it, not just loaded. I reproduced this test failure with a small standalone program similar to the test app, showing how initially the print of java.lang.Long.MAX_VALUE fails, but then succeeds after a reference to it. $ build/linux-x64-debug/images/jdk/bin/jdb Test Initializing jdb ... > stop at Test:10 Deferring breakpoint Test:10. It will be set after the class is loaded. > run run Test Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint Test:10 Breakpoint hit: "thread=main", Test.bkpt(), line=10 bci=2 10 Long l = new Long(java.lang.Long.MAX_VALUE); // force loading of Long class main[1] print java.lang.Long.MAX_VALUE com.sun.tools.example.debug.expr.ParseException: Name unknown: java.lang.Long.MAX_VALUE java.lang.Long.MAX_VALUE = null main[1] next > Step completed: "thread=main", Test.bkpt(), line=11 bci=13 11 } main[1] print java.lang.Long.MAX_VALUE java.lang.Long.MAX_VALUE = 9223372036854775807
10-05-2018
This failure was introduced by JDK-8198426, which removed some VM startup code executed in Java, which seems to have had the side effect of making it so java.lang.Long is no longer loaded at startup. The following diff fixes the test: diff --git a/test/jdk/com/sun/jdi/JdbExprTest.sh b/test/jdk/com/sun/jdi/JdbExprTest.sh --- a/test/jdk/com/sun/jdi/JdbExprTest.sh +++ b/test/jdk/com/sun/jdi/JdbExprTest.sh @@ -47,6 +47,7 @@ class $classname { + static Long l = new Long(java.lang.Long.MAX_VALUE); // force loading of Long class static long aLong; static int anInt; static boolean aBoolean;
09-05-2018
It seems to be failing on every run now. Should be quarantined.
23-04-2018
Oddly, this test always fails with Windows JDKs that I built using JPRT (both fastdebug and product) but always passes with Windows JDKs that I built on my laptop. The JDK source for the JPRT builds was the same as the source used to build on my laptop. The test always passes with any JDK (either built by JPRT or built on my laptop) when the JDB commands are entered by hand.
11-08-2017
I'm not seeing any indication that this bug has happened before the 2017-08-01 JDK10-hs nightly. That indicates that what ever broke this test is only in JDK10-hs which means this bug is an integration_blocker. I've changed the Fix Version back to '10' and added the integration_blocker label. Yes, I realize that the test is quarantined and that would count as resolution of an integration_blocker label if we knew that this failure is related to a test bug. However, we don't know the reason for this test failure (yet).
10-08-2017