JDK-8209605 : com/sun/jdi/BreakpointWithFullGC.java fails with ZGC
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-08-16
  • Updated: 2020-08-27
  • Resolved: 2018-08-22
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 JDK 12
11.0.10-oracleFixed 12 b09Fixed
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8209608 :  
Description
The test fails when run with -XX:+UseZGC -Xmx32m:

[debuggee] [0.031s][info][gc] Using The Z Garbage Collector
[debuggee] Error occurred during initialization of VM
[debuggee] java.lang.OutOfMemoryError: Java heap too small
	Thread[MainThread,5,MainThreadGroup] stack: (length = 14)
	java.base@12-internal/java.lang.Thread.dumpThreads(Native Method)
	java.base@12-internal/java.lang.Thread.getAllStackTraces(Thread.java:1657)
	app//jdk.test.lib.process.ProcessTools.startProcess(ProcessTools.java:252)
	app//lib.jdb.Jdb.<init>(Jdb.java:90)
	app//lib.jdb.Jdb.launchLocal(Jdb.java:64)
	app//lib.jdb.JdbTest.setup(JdbTest.java:57)
	app//lib.jdb.JdbTest.run(JdbTest.java:49)
	app//BreakpointWithFullGC.main(BreakpointWithFullGC.java:66)
	java.base@12-internal/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	java.base@12-internal/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	java.base@12-internal/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	java.base@12-internal/java.lang.reflect.Method.invoke(Method.java:566)
	app//com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	java.base@12-internal/java.lang.Thread.run(Thread.java:834)

	Thread[Finalizer,8,system] stack: (length = 4)
	java.base@12-internal/java.lang.Object.wait(Native Method)
	java.base@12-internal/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155)
	java.base@12-internal/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:176)
	java.base@12-internal/java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:170)

	Thread[Signal Dispatcher,9,system] stack: (length = 0)

	Thread[Common-Cleaner,8,InnocuousThreadGroup] stack: (length = 5)
	java.base@12-internal/java.lang.Object.wait(Native Method)
	java.base@12-internal/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155)
	java.base@12-internal/jdk.internal.ref.CleanerImpl.run(CleanerImpl.java:148)
	java.base@12-internal/java.lang.Thread.run(Thread.java:834)
	java.base@12-internal/jdk.internal.misc.InnocuousThread.run(InnocuousThread.java:134)

	Thread[Reference Handler,10,system] stack: (length = 3)
	java.base@12-internal/java.lang.ref.Reference.waitForReferencePendingList(Native Method)
	java.base@12-internal/java.lang.ref.Reference.processPendingReferences(Reference.java:241)
	java.base@12-internal/java.lang.ref.Reference$ReferenceHandler.run(Reference.java:213)

	Thread[main,5,main] stack: (length = 4)
	java.base@12-internal/java.lang.Object.wait(Native Method)
	java.base@12-internal/java.lang.Thread.join(Thread.java:1305)
	java.base@12-internal/java.lang.Thread.join(Thread.java:1379)
	app//com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:74)

----------System.err:(16/897)----------
Failed to start a process (thread dump follows)
java.lang.NullPointerException
	at lib.jdb.JdbTest.shutdown(JdbTest.java:66)
	at lib.jdb.JdbTest.run(JdbTest.java:52)
	at BreakpointWithFullGC.main(BreakpointWithFullGC.java:66)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:834)

Comments
Fix Request (11u) This backport improves testing and matches the codebases better (I see 11.0.10-oracle). Patch applies cleanly to 11u, affected com/sun/jdi tests pass in {fastdebug,release}. This bunch contains a rewrite and a few follow-ups: JDK-8209109, JDK-8209517, JDK-8209605, JDK-8203393.
25-08-2020

One more issue with the original test (BreakpointWithFullGC.sh): it used: # make sure we had at least one full GC # Prior to JDK9-B95, the pattern was 'Full GC' debuggeeMatchRegexp '^.*?\bPause Full\b\(System.gc\(\)\)\b.*?$' Which was converted to new OutputAnalyzer(jdb.getDebuggeeOutput()) // make sure we had at least one full GC // Prior to JDK9-B95, the pattern was 'Full GC' .stdoutShouldContain("Pause Full (System.gc())") (because original regexp does not work with java regexp) But actually it didn't work with sed as well: sed: -e expression #1, char 1: unknown command: `^' Also debuggeeMatchRegexp does not require debuggee output contains the string which mathes the regexp, it's informative only. Some GCc (including ZGC) does not produce required string for full GC, so this condition (stdoutShouldContain("Pause Full (System.gc())")) should be dropped from BreakpointWithFullGC.java
18-08-2018

There are several issues here: 1. failure with ZGC (OutOfMemoryError) Before converting from shell to java ShellScaffold.sh added the specified debugee arguments ("-Xmx32m -verbose:gc") to the beginning of the command line, so common test argumets (added later in the command line) can override them. In the case we have "java -Xmx32m -verbose:gc ... -Xmx512m ...", i.e. -Xmx32m is not effective. This is a bug in ShellScaffold.sh, but for java version -Xmx arg should be updated (or dropped) 2. ArrayIndexOutOfBoundsException String.split(separator) can return 0-length array when the string contains only the separator. Need to use String.split(separator, -1) to avoid discarding of empty strings 3. Need to improve error handling: a) if debuggee or jdb fails to launch, JdbTest.jdb is null, JdbTest.shutdown should handle the case properly b) if debuggee is started successfully, but jdb is failed to start, debuggee process should be terminated
17-08-2018

The AIOOBE issue is also seen in jdk/com/sun/jdi/ArrayLengthDumpTest.java.
17-08-2018

There's an alternative failure mode for this which is not ZGC specific: java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at lib.jdb.Jdb$OutputHandler.get(Jdb.java:363) at lib.jdb.Jdb.waitForPrompt(Jdb.java:247) at lib.jdb.Jdb.command(Jdb.java:288) at BreakpointWithFullGC.runCases(BreakpointWithFullGC.java:87) at lib.jdb.JdbTest.run(JdbTest.java:50) at BreakpointWithFullGC.main(BreakpointWithFullGC.java:66) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:834) For now I'll update the bug to include/cover that failure mode as well.
17-08-2018

Alex, can you take a look at this one?
16-08-2018