Bug ID: JDK-8305420 VMConnection.open blocks if child process has lots of output

JDK-8305420 : VMConnection.open blocks if child process has lots of output

Type: Bug
Component: core-svc
Sub-Component: debugger

Priority: P4
Status: Closed
Resolution: Duplicate

Submitted: 2023-04-02
Updated: 2023-04-03
Resolved: 2023-04-03

Related Reports

Duplicate :

JDK-8173304 - com.sun.tools.jdi.SunCommandLineLauncher.launch hangs if debugee VM produces too much output during VM startup

Sub Tasks

JDK-8305421 :

Work around JDK-8305420 in CDSJDITest.java - Resolved

Description

Test case (fails on Windows only):

make test-only \
  TEST=open/test/jdk/com/sun/jdi/cds/CDSBreakpointTest.java \
  JTREG_JAVA_OPTIONS=-XX:ArchiveRelocationMode=1

The test will timeout because BreakpointTest.java gets stuck while trying to launch a debugee VM:

=============
   JavaThread state: _thread_blocked
	at java.lang.Object.wait0(java.base@21-internal/Native Method)
	- waiting on <0x00000000ef99f518> (a com.sun.tools.jdi.AbstractLauncher$Helper)
	at java.lang.Object.wait(java.base@21-internal/Object.java:366)
	at java.lang.Object.wait(java.base@21-internal/Object.java:339)
	at com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept(jdk.jdi@21-internal/AbstractLauncher.java:197)
	- locked <0x00000000ef99f518> (a com.sun.tools.jdi.AbstractLauncher$Helper)
	at com.sun.tools.jdi.AbstractLauncher.launch(jdk.jdi@21-internal/AbstractLauncher.java:140)
	at com.sun.tools.jdi.SunCommandLineLauncher.launch(jdk.jdi@21-internal/SunCommandLineLauncher.java:233)
	at VMConnection.launchTarget(VMConnection.java:314)
	at VMConnection.open(VMConnection.java:149)
	- locked <0x00000000efa00300> (a VMConnection)
	at TestScaffold.connect(TestScaffold.java:652)
	at TestScaffold.startUp(TestScaffold.java:367)
	at TestScaffold.startTo(TestScaffold.java:377)
	at TestScaffold.startToMain(TestScaffold.java:372)
	at BreakpointTest.runTests(BreakpointTest.java:129)
	at TestScaffold.startTests(TestScaffold.java:434)
	at BreakpointTest.main(BreakpointTest.java:82)
===============

But the debugee VM is stuck while it tries to write to the stdout, which isn't drained by BreakpointTest:

=================
LogFileStreamOutput::flush() Line 93
LogFileStreamOutput::write(const LogDecorations & decorations, const char * msg) Line 166
LogTagSet::log(LogLevel::type level, const char * msg) Line 84
LogTagSet::vwrite(LogLevel::type level, const char * fmt, char * args) Line 149
LogImpl<14,107,0,0,0,0>::vwrite(LogLevel::type level, const char * fmt, char * args) Line 149
LogImpl<14,107,0,0,0,0>::write<3>(const char * fmt, ...) Line 143
SharedClassPathEntry::validate(bool is_class_path) Line 423
FileMapInfo::validate_shared_path_table() Line 1067
MetaspaceShared::map_archive(FileMapInfo * mapinfo, char * mapped_base_address, ReservedSpace rs) Line 1397
MetaspaceShared::map_archives(FileMapInfo * static_mapinfo, FileMapInfo * dynamic_mapinfo, bool use_requested_addr) Line 1095
MetaspaceShared::initialize_runtime_shared_and_meta_spaces() Line 922
Metaspace::global_initialize() Line 757
universe_init() Line 792
init_globals() Line 124
Threads::create_vm(JavaVMInitArgs * args, bool * canTryAgain) Line 568
JNI_CreateJavaVM_inner(JavaVM_ * * vm, void * * penv, void * args) Line 3588
JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * args) Line 3674
InitializeJVM(const JNIInvokeInterface_ * * * pvm, const JNINativeInterface_ * * * penv, InvocationFunctions * ifn) Line 1459
JavaMain(void * _args) Line 413
ThreadJavaMain(void * args) Line 705
=================

Comments

Closing as a duplicate of JDK-8173304.
03-04-2023
Only bug associated with a changeset should be closed as fixed.
03-04-2023
Closing as a duplicate of JDK-8173304
03-04-2023
The failure in CDSBreakpointTest.java is related to this line in CDSJDITest.java https://github.com/openjdk/jdk/blob/aa762102e9328ca76663b56b3be6f6141b044744/test/jdk/com/sun/jdi/cds/CDSJDITest.java#L64 // Args to the Main Class: // These argument all follow the above <testname> argument, and are // in fact passed to <testname>.main() as java arguments. <testname> will // pass them as JVM arguments to the debuggee process it creates. "-Xbootclasspath/a:" + appJar, "-XX:+UnlockDiagnosticVMOptions", "-Xlog:class+path=info", // <<<<<<<<<<<<<< HERE "-XX:SharedArchiveFile=./SharedArchiveFile.jsa", "-Xshare:on", "-showversion" When running without JTREG_JAVA_OPTIONS=-XX:ArchiveRelocationMode=1, the logging looks like this: ================== [0.014s][info][class,path] bootstrap loader class path=C:\ade\win\build\windows-x64-slowdebug\images\jdk\lib\modules;C:/ade/win/build/windows-x64-slowdebug/test-support/jtreg_open_test_jdk_com_sun_jdi_cds_CDSBreakpointTest_java/classes/0/com/sun/jdi/cds/CDSBreakpointTest.d/BreakpointTest.jar [0.017s][info][class,path] opened: C:/ade/win/build/windows-x64-slowdebug/test-support/jtreg_open_test_jdk_com_sun_jdi_cds_CDSBreakpointTest_java/classes/0/com/sun/jdi/cds/CDSBreakpointTest.d/BreakpointTest.jar [0.036s][info][class,path] Expecting BOOT path=C:\ade\win\build\windows-x64-slowdebug\images\jdk\lib\modules;C:/ade/win/build/windows-x64-slowdebug/test-support/jtreg_open_test_jdk_com_sun_jdi_cds_CDSBreakpointTest_java/classes/0/com/sun/jdi/cds/CDSBreakpointTest.d/BreakpointTest.jar [0.036s][info][class,path] Expecting -Djava.class.path=C:/ade/win/build/windows-x64-slowdebug/test-support/jtreg_open_test_jdk_com_sun_jdi_cds_CDSBreakpointTest_java/classes/0/com/sun/jdi/cds/CDSBreakpointTest.d;C:/ade/win/open/test/jdk/com/sun/jdi/cds;C:/ade/win/build/windows-x64-slowdebug/test-support/jtreg_open_test_jdk_com_sun_jdi_cds_CDSBreakpointTest_java/classes/0/com/sun/jdi;C:/ade/win/build/windows-x64-slowdebug/test-support/jtreg_open_test_jdk_com_sun_jdi_cds_CDSBreakpointTest_java/classes/0/test/lib;C:/cygwin64/var/tmp/jib-iklam/install/jtreg/7.1.1/1/bundles/jtreg-7.1.1+1.zip/jtreg/lib/jtreg.jar;C:/cygwin64/var/tmp/jib-iklam/install/jtreg/7.1.1/1/bundles/jtreg-7.1.1+1.zip/jtreg/lib/junit-platform-console-standalone-1.8.2.jar;C:/cygwin64/var/tmp/jib-iklam/install/jtreg/7.1.1/1/bundles/jtreg-7.1.1+1.zip/jtreg/lib/testng-7.3.0.jar;C:/cygwin64/var/tmp/jib-iklam/install/jtreg/7.1.1/1/bundles/jtreg-7.1.1+1.zip/jtreg/lib/jcommander-1.78.jar;C:/cygwin64/var/tmp/jib-iklam/install/jtreg/7.1.1/1/bundles/jtreg-7.1.1+1.zip/jtreg/lib/guice-4.2.3.jar [0.037s][info][class,path] checking shared classpath entry: C:\ade\win\build\windows-x64-slowdebug\images\jdk\lib\modules [0.037s][info][class,path] ok [0.037s][info][class,path] checking shared classpath entry: C:/ade/win/build/windows-x64-slowdebug/test-support/jtreg_open_test_jdk_com_sun_jdi_cds_CDSBreakpointTest_java/classes/0/com/sun/jdi/cds/CDSBreakpointTest.d/BreakpointTest.jar [0.037s][info][class,path] ok [0.037s][info][class,path] should be non-existent: javatest.jar [0.037s][info][class,path] ok [0.037s][info][class,path] should be non-existent: asmtools.jar [0.037s][info][class,path] ok ================= When running WITH JTREG_JAVA_OPTIONS=-XX:ArchiveRelocationMode=1, the lines starting from "Expecting BOOT path" is printed twice. Apparently this is too much for the Windows pipe buffer.
02-04-2023