JDK-8150301 : jdwp breakpoint001 test hangs
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-02-19
  • Updated: 2016-02-26
  • Resolved: 2016-02-26
Related Reports
Duplicate :  
JDK-6303969 - JDWP: Socket Transport handshake fails rarely on InstancesTest.java
Relates :  
JDK-6868436 - JDWP: superclass001 test hangs intermittently
Relates :  
JDK-6303969 - JDWP: Socket Transport handshake fails rarely on InstancesTest.java
Description
[2016-02-19T05:39:00.29] >>> Starting debugee 
[2016-02-19T05:39:00.29] 
[2016-02-19T05:39:00.30] Launching debugee
[2016-02-19T05:39:00.33] Debugee> Starting java process:
[2016-02-19T05:39:00.33] "/export/local/aurora/CommonData/JDK_DIR/bin/java" "-d64" "-server" "-Xcomp" "-XX:MaxRAMFraction=8" "-XX:+CreateCoredumpOnCrash" "-XX:NativeMemoryTracking=detail" "-XX:ReservedCodeCacheSize=256M" "-Xdebug" "-Xrunjdwp:server=n,transport=dt_socket,address=localhost:42427" "nsk.jdwp.Event.BREAKPOINT.breakpoint001a" "-arch=solaris-amd64" "-verbose" "-waittime=5" "-debugee.vmkind=java" "-transport.address=dynamic" "-debugee.vmkeys=-d64 -server -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=256M" "-pipe.port=64201"
[2016-02-19T05:39:00.48] Debugee> Establishing JDWP socket connection
[2016-02-19T05:39:00.48] Debugee> Listening from debugee
[2016-02-19T06:10:05.88] [2016-02-19T06:10:05.88] # Test level exit status: 151
Comments
This one is an instance of a much older bug: JDK-6303969 JDWP: Socket Transport handshake fails rarely on InstancesTest.java so I don't think this one is an integration_blocker. Update: the key piece is the hang in post_vm_initialized() with the socket code.
23-02-2016
Given this is a one-of failure on Solaris (all bulk failures have been on Linux) this may be an indicator of an actual problem. It looks like the debuggee VM is still somewhere in VM initialization when the timeout happens. ----------------- lwp# 2 / thread# 2 -------------------- ffff80ffbf51dbca recv (6, ffff80ffbf14e2a0, e, 0) ffff80ffbf68fe2e recv () + 12 ffff80faeba03e5e dbgsysRecv () + 2e ffff80faeba03702 recv_fully () + 32 ffff80faeba02a08 handshake () + 68 ffff80faeba0336e socketTransport_attach () + ce ffff80faebc39eba transport_startTransport () + 7a ffff80faebc2256a startTransport () + 6a ffff80faebc1f2cf bagEnumerateOver () + 3f ffff80faebc22acd initialize () + 1dd ffff80faebc21d39 cbEarlyVMInit () + 79 ffff80fad3c22c72 __1cLJvmtiExportTpost_vm_initialized6F_v_ () + 622 ffff80fad41cb2c9 __1cHThreadsJcreate_vm6FpnOJavaVMInitArgs_pb_i_ () + 6d9 ffff80fad3a6385f __1cWJNI_CreateJavaVM_inner6FppnHJavaVM__ppv3_i_ () + 7f ffff80fad3a63d99 JNI_CreateJavaVM () + 9 ffff80faed00cb5b InitializeJVM () + 11b ffff80faed00aad9 JavaMain () + 59 ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start ()
21-02-2016
@Jesper Not sure this is an integration_blocker or not. I think it isn't, but I'll leave it up to your judgement.
21-02-2016