subject:"Re\: RFR\: 8201409\: JDWP debugger initialization hangs intermittently"

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-05-03 Thread serguei.spit...@oracle.com


  
  
Hi Andrew,
  
  Okay, thanks!
  Serguei
  
  
  On 5/3/18 07:18, Andrew Leonard wrote:


  
  Hi Serguei,
  
  I've done some
debug, and there seems to be some difference in behaviour with
Hotspot
with regards the report VM_INIT command, i'm not sure I quite
understand
why... so i'm consulting with a colleague to get some help. 
  
  I'll update the
bug when I have some more information.
  
  Thanks
  
  Andrew
  
  
  Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 
  
  
  
  
  
  From:
       "serguei.spit...@oracle.com"
<serguei.spit...@oracle.com>
  
  To:
       Andrew
Leonard <andrew_m_leon...@uk.ibm.com>
  
  Cc:
       serviceability-dev@openjdk.java.net
  
  Date:
       24/04/2018
01:47
  
  Subject:
           Re:
    RFR: 8201409: JDWP debugger initialization hangs intermittently
  
  
  
  
  
  The most relevant stack traces from Solaris
pstack dump are:

  12 -  lwp# 2 / thread# 2  
  13  7eae9b3c lwp_cond_wait (100123448, 100123430, 0,
0)
  14  fffd12331a94 void os::PlatformEvent::park()
(100123400,
e6c40, e6c00, 0, fffd12adbf00, 100123430) + c4
  15  fffd122c6038 int Monitor::IWait(Thread*,long)
(100122f30,
100122000, 0, fffd12b4dba8, 0, 100122f50) + 98
  16  fffd122c6a4c bool Monitor::wait(bool,long,bool)
(100122f30,
1, 0, 0, 2155, 100122000) + 7c
  17  fffd125464e8 int JavaThread::java_suspend_self()
(100122000,
1, 4000, 1001220b8, 100122f30, 100122f30) + a8
  18  fffd120c84a4 int
JvmtiRawMonitor::raw_wait(long,bool,Thread*)
(10079e3b0, 10079e430, 1, 100122000, 94400, fffd12b70600) +
254
  19  fffd120942ec jvmtiError
JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long)
(4, 10079e3b0, , 100122000, 0, fffd12adbf00)
+ 5c
  20  fffd0f8385bc debugMonitorWait (fffd0f946268, c10,
c00, fffd0f945580, fffd0f945580, 0) + 3c
  21  fffd0f825140 enqueueCommand (1007a0a20,
ffefc418,
103800, ffefc3e8, 0, fffd0f945580) + 140
  22  fffd0f826e58 eventHelper_reportEvents (0, 10079a000,
0, 1007a0a20, 1, 1) + 108
  23  fffd0f81b4c0 initialize (1001222e0, c00, 4,
fffd0f83edc0,
fffd0f9460d0, fffd0f945580) + 540
  24  fffd0f81a77c cbEarlyException (fffd0f946190,
1001222e0,
1005953a0, fffd0f83eaa0, fffd0f946268, 1005953a8) + 21c
  25  fffd120af6a4 void
JvmtiExport::post_exception_throw(JavaThread*,Method*,unsigned
char*,oopDesc*) (100122000, fffd12b78f38, 100764b40,
62cb91b50, 100122d48,
fffd12b7a618) + 15b4
  26  fffd11c27484 unsigned
char*InterpreterRuntime::exception_handler_for_exception(JavaThread*,oopDesc*)(0,
4a0014e0, 100122000, 4a001470, 100122d40,
fffd12adbf00)
+ 704
  27  6100eac0 * JITDebug.debugTarget()V+29
  28  61009ecc *
JITDebug.parseArgs([Ljava/lang/String;)Z+50
  29  610084ac * JITDebug.main([Ljava/lang/String;)V+8
  30  610003c0  (7d0ffc20,
7d0ffe30,
a, 4a000f18, 6100ff40, 7d0ffd78) +
fff8006cc46de0b0
  31  fffd11c43134 void
JavaCalls::call_helper(JavaValue*,const
methodHandle&,JavaCallArguments*,Thread*) (7d0ffe28,
4a000f18,
7d0ffd68, 7d0ffde8, e, 61000340) + 2e4
  32  fffd11cfd95c jni_CallStaticVoidMethod (1001222e0,
1400,
1c, 7d0ffde8, 100122000, 153d) + 5bc
  33  fffd12c0603c JavaMain (ac8, 100123780, 100123798, 1,
fffd12b605f0, fffd11cfd3a0) + 81c
  34  7eae4b38 _lwp_start (0, 0, 0, 0, 0, 0)

 216 -  lwp# 18 / thread# 18 

 217  7eae9b3c lwp_cond_wait (10078cd48, 10078cd30, 0,
0)
 218  fffd12331a94 void os::PlatformEvent::park()
(10078cd00,
e6c40, e6c00, 0, fffd12adbf00, 10078cd30) + c4
 219  fffd120c7b00 int
JvmtiRawMonitor::SimpleWait(Thread*,long)
(10078a470, 10079c000, ff

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-05-03 Thread Andrew Leonard

Hi Serguei,
I've done some debug, and there seems to be some difference in behaviour 
with Hotspot with regards the report VM_INIT command, i'm not sure I quite 
understand why... so i'm consulting with a colleague to get some help. 
I'll update the bug when I have some more information.
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   "serguei.spit...@oracle.com" <serguei.spit...@oracle.com>
To: Andrew Leonard <andrew_m_leon...@uk.ibm.com>
Cc: serviceability-dev@openjdk.java.net
Date:   24/04/2018 01:47
Subject:    Re: RFR: 8201409: JDWP debugger initialization hangs 
intermittently



The most relevant stack traces from Solaris pstack dump are:

  12 -  lwp# 2 / thread# 2  
  13  7eae9b3c lwp_cond_wait (100123448, 100123430, 0, 0)
  14  fffd12331a94 void os::PlatformEvent::park() (100123400, e6c40, 
e6c00, 0, fffd12adbf00, 100123430) + c4
  15  fffd122c6038 int Monitor::IWait(Thread*,long) (100122f30, 
100122000, 0, fffd12b4dba8, 0, 100122f50) + 98
  16  fffd122c6a4c bool Monitor::wait(bool,long,bool) (100122f30, 1, 
0, 0, 2155, 100122000) + 7c
  17  fffd125464e8 int JavaThread::java_suspend_self() (100122000, 1, 
4000, 1001220b8, 100122f30, 100122f30) + a8
  18  fffd120c84a4 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) 
(10079e3b0, 10079e430, 1, 100122000, 94400, fffd12b70600) + 254
  19  fffd120942ec jvmtiError 
JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (4, 10079e3b0, 
, 100122000, 0, fffd12adbf00) + 5c
  20  fffd0f8385bc debugMonitorWait (fffd0f946268, c10, c00, 
fffd0f945580, fffd0f945580, 0) + 3c
  21  fffd0f825140 enqueueCommand (1007a0a20, ffefc418, 
103800, ffefc3e8, 0, fffd0f945580) + 140
  22  fffd0f826e58 eventHelper_reportEvents (0, 10079a000, 0, 
1007a0a20, 1, 1) + 108
  23  fffd0f81b4c0 initialize (1001222e0, c00, 4, fffd0f83edc0, 
fffd0f9460d0, fffd0f945580) + 540
  24  fffd0f81a77c cbEarlyException (fffd0f946190, 1001222e0, 
1005953a0, fffd0f83eaa0, fffd0f946268, 1005953a8) + 21c
  25  fffd120af6a4 void 
JvmtiExport::post_exception_throw(JavaThread*,Method*,unsigned 
char*,oopDesc*) (100122000, fffd12b78f38, 100764b40, 62cb91b50, 
100122d48, fffd12b7a618) + 15b4
  26  fffd11c27484 unsigned 
char*InterpreterRuntime::exception_handler_for_exception(JavaThread*,oopDesc*) 
(0, 4a0014e0, 100122000, 4a001470, 100122d40, 
fffd12adbf00) + 704
  27  6100eac0 * JITDebug.debugTarget()V+29
  28  61009ecc * JITDebug.parseArgs([Ljava/lang/String;)Z+50
  29  610084ac * JITDebug.main([Ljava/lang/String;)V+8
  30  610003c0  (7d0ffc20, 7d0ffe30, a, 
4a000f18, 6100ff40, 7d0ffd78) + fff8006cc46de0b0
  31  fffd11c43134 void JavaCalls::call_helper(JavaValue*,const 
methodHandle&,JavaCallArguments*,Thread*) (7d0ffe28, 
4a000f18, 7d0ffd68, 7d0ffde8, e, 61000340) 
+ 2e4
  32  fffd11cfd95c jni_CallStaticVoidMethod (1001222e0, 1400, 1c, 
7d0ffde8, 100122000, 153d) + 5bc
  33  fffd12c0603c JavaMain (ac8, 100123780, 100123798, 1, 
fffd12b605f0, fffd11cfd3a0) + 81c
  34  7eae4b38 _lwp_start (0, 0, 0, 0, 0, 0)

 216 -  lwp# 18 / thread# 18  
 217  7eae9b3c lwp_cond_wait (10078cd48, 10078cd30, 0, 0)
 218  fffd12331a94 void os::PlatformEvent::park() (10078cd00, e6c40, 
e6c00, 0, fffd12adbf00, 10078cd30) + c4
 219  fffd120c7b00 int JvmtiRawMonitor::SimpleWait(Thread*,long) 
(10078a470, 10079c000, , fffd120c50e0, 1, 0) + 100
 220  fffd120c8328 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) 
(10078a470, , 1, 10079c000, ffd880ac, 
fffd12adbf00) + d8
 221  fffd120942ec jvmtiError 
JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (4, 10078a470, 
, 10079c000, 0, fffd12adbf00) + 5c
 222  fffd0f8385bc debugMonitorWait (fffd0f946268, c10, c00, 
fffd0f945580, fffd0f946190, 0) + 3c
 223  fffd0f81adac debugInit_waitVMInitComplete (0, f28, 
fffd0f945580, c00, fffd0f844888, 1) + 3c
 224  fffd0f81caac debugLoop_run (105c00, f50, fffd0f945580, 1, 
fffd0f9464d0, 0) + 6c
 225  fffd0f8335b4 connectionInitiated (fffd0f705250, 1000, 1, 
fffd0f945580, fffd0f9468d8, 0) + e4
 226  fffd0f833800 acceptThread (0, fffd0f705260, 1007973c0, 
fffd0f843de0, fffd0f945580, fffd0f946190) + 110
 227  fffd120c0934 void JvmtiAgentThread::call_start_function() 
(10079c000, 0, 0, fffd12adbf00, fffd12b78f38, 0) + 1b4
 228  fffd125445fc void JavaThread::thread_main_inner() (

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-24 Thread Andrew Leonard

Hi Serguei,
Good find, i'll try it out and do some debugging.
Many thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   "serguei.spit...@oracle.com" <serguei.spit...@oracle.com>
To: Andrew Leonard <andrew_m_leon...@uk.ibm.com>
Cc: serviceability-dev@openjdk.java.net
Date:   24/04/2018 01:03
Subject:    Re: RFR: 8201409: JDWP debugger initialization hangs 
intermittently



On 4/23/18 16:08, serguei.spit...@oracle.com wrote:
Hi Andrew,

There is a regression with this fix.
The following test is failed with timeout on all platforms except Windows:

Sorry, forgot to copy the test name:
  open/test/jdk/com/sun/jdi/JITDebug.sh


Thanks,
Serguei


I'll try to get more details about this timeout.

Thanks,
Serguei


On 4/18/18 09:49, serguei.spit...@oracle.com wrote:
Hi Andrew,

Sorry, I did not reply earlier.
The fix need more testing. We also have some important tests in closed.
I'll run them but I'm a little bit busy at the moment.

You have two reviews which is enough for push after testing.

Thanks,
Serguei


On 4/18/18 08:23, Andrew Leonard wrote:
Hi Serguei, 
Do you need me to try anything else for this review? 
hotspot/jtreg/serviceability suite run successfully. 
Many Thanks 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:"serguei.spit...@oracle.com" <serguei.spit...@oracle.com> 
To:daniel.daughe...@oracle.com, Andrew Leonard 
<andrew_m_leon...@uk.ibm.com> 
Cc:serviceability-dev@openjdk.java.net 
Date:        16/04/2018 07:10 
Subject:Re: RFR: 8201409: JDWP debugger initialization hangs 
intermittently 



On 4/15/18 10:01, Daniel D. Daugherty wrote: 
On 4/13/18 3:07 PM, serguei.spit...@oracle.com wrote: 
Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that includes the bug 
number.

The issues is:
  https://bugs.openjdk.java.net/browse/JDK-8201409

Webrev:
  
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/ 

 
src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
So now pauses in debugLoop_run() before the loop
that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
So the VM_INIT event handler now signals that we have
received the VM_INIT event so that allows debugLoop_run()
to proceed.

Serguei, this fix needs to have the most of the Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb tests).
Based on the email thread, I can't tell which tests have been
run with the fix in place. 

Hi Dan,

I'm going to sponsor this fix and will run all the debugger tests.
Sorry that I did not announce it yet.

Thanks,
Serguei


Dan



The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for this issue is not 
easy.

At least, one more review is needed before the fix can be pushed.

Thanks,
Serguei


On 4/11/18 06:33, Andrew Leonard wrote: 
Hi Serguei, 
Thank you for raising the bug. 
I had a chat with one of my colleagues who could recreate it, and it's 
probably related to the handshaking that is done in the particular 
scenario. So with the JCK harness: 

com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck
/jck8b/natives/linux_x86-64 /projects/jck/jdwp/j2sdk-image/bin/java 
-Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache 
-Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache 
-Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache 
-Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache -
Xfuture -agentlib:jdwp=server=y,transport=dt_socket,address=localhost
:35000,suspend=y -classpath /javatest/lib/jck
/JCK8b-b03/JCK-runtime-8b/classes -Djava.security.policy=/javatest/lib/jck
/JCK8b-b03/JCK-runtime-8b/lib/jck.policy 
javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600 
-msgSwitch=ub1604x64vm10:38636 -componentName=
ArrayReference.GetValues.getvalues002 

Note that the JCK test harness starts the target process, attaches to it, 
and sends the resume command 
in a very short time with no handshaking. 

That may not help..but hopefully helps explain things a bit? It's the 
timing of the resume command during the test that is crucial, resuming 
before the VM initialization is complete will trigger it. 

Thanks 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:"serguei.spit...@oracle.com" <serguei.spit...@oracle.com>

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-23 Thread serguei.spit...@oracle.com

ait(long,bool,Thread*) (10079e4b0,
  , 1, 10079e800, ffd880ac,
  fffd12adbf00) + d8
   237  fffd120942ec jvmtiError
  JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (4, 10079e4b0,
  , 10079e800, 0, fffd12adbf00) + 5c
   238  fffd0f8385bc debugMonitorWait (fffd0f946268, c10,
  c00, fffd0f945580, fffd0f946190, 0) + 3c
   239  fffd0f8261f8 doBlockCommandLoop (800, 1028,
  fffd0f945580, 1000, fffd0f945580, 0) + 48
   240  fffd0f826448 commandLoop (c10, 10079eae0, 1,
  fffd0f945580, fffd0f94612c, 1007a0a20) + f8
   241  fffd120c0934 void
  JvmtiAgentThread::call_start_function() (10079e800, 0, 0,
  fffd12adbf00, fffd12b78f38, 0) + 1b4
   242  fffd125445fc void JavaThread::thread_main_inner()
  (10079e800, 3d8, 1005c1a78, 1005c16a0, 48affb38,
  fffd12bb62a0) + 8c
   243  fffd12544534 void JavaThread::run() (10079e800, c, 13,
  62cb92d50, 0, 18) + 4a4
   244  fffd12324ca0 thread_native_entry (0, 10079e800, 0,
  10079d0e0, fffd12adbf00, 50dc) + 320
   245  7eae4b38 _lwp_start (0, 0, 0, 0, 0, 0)
   246 -  lwp# 20 / thread# 20  
   247  7eae906c recv (7, 488ff7b4, 4, 0)
   248  7e40dba8 recv (7, 7fff, 4, 0, 7c00,
  1007a1000) + 1c
   249  fffd0f603f70 dbgsysRecv (7, 488ff7b4, 4, 0,
  1007a1000, a0910) + 10
   250  fffd0f6034e4 recv_fully (7, 488ff7b4, 4, a0800,
  0, 0) + 24
   251  fffd0f603634 socketTransport_readPacket (598,
  488ff920, 10, fffd0f704cb0, fffd0f604bb0, 0) +
  54
   252  fffd0f8341c0 transport_receivePacket (488ff920,
  be8, 800, fffd0f945580, 10079a180, 1) + 30
   253  fffd0f81cd30 reader (0, ffefa490,
  fffd0f945580, 105800, 488ff920, fffd0f83fa10) + 60
   254  fffd120c0934 void
  JvmtiAgentThread::call_start_function() (1007a1000, 0, 0,
  fffd12adbf00, fffd12b78f38, 0) + 1b4
   255  fffd125445fc void JavaThread::thread_main_inner()
  (1007a1000, 3d8, 1005c1e78, 1005c1aa0, 488ffab8,
  fffd12bb62a0) + 8c
   256  fffd12544534 void JavaThread::run() (1007a1000, d, 14,
  62cbeb9e8, 72, 13) + 4a4
   257  fffd12324ca0 thread_native_entry (0, 1007a1000, 0,
  1007a0ab0, fffd12adbf00, 50dc) + 320
   258  7eae4b38 _lwp_start (0, 0, 0, 0, 0, 0)
  
  
  
  
  
  
  On 4/23/18 17:02, serguei.spit...@oracle.com wrote:


  
  On 4/23/18 16:08, serguei.spit...@oracle.com wrote:
  
  
Hi Andrew,
  
  There is a regression with this fix.
  The following test is failed with timeout on all platforms
  except Windows:

  
  
  Sorry, forgot to copy the test name:
    open/test/jdk/com/sun/jdi/JITDebug.sh
  
  
  Thanks,
  Serguei
  
  
  
 I'll try to get more details about
  this timeout.
  
  Thanks,
  Serguei
  
  
  On 4/18/18 09:49, serguei.spit...@oracle.com wrote:


  Hi Andrew,

Sorry, I did not reply earlier.
The fix need more testing. We also have some important tests
in closed.
I'll run them but I'm a little bit busy at the moment.

You have two reviews which is enough for push after testing.

Thanks,
Serguei


On 4/18/18 08:23, Andrew Leonard wrote:
  
  
Hi Serguei, 
Do you need me to try anything else for this review?
  hotspot/jtreg/serviceability suite run successfully.

Many Thanks 
Andrew 

Andrew Leonard
  Java Runtimes Development
  IBM Hursley
  IBM United Kingdom Ltd
  Phone internal: 245913, external: 01962 815913
  internet email: andrew_m_leon...@uk.ibm.com 





From:        "serguei.spit...@oracle.com"
  <serguei.spit...@oracle.com>

To:        daniel.daughe...@oracle.com,
  Andrew Leonard <andrew_m_leon...@uk.ibm.com>

Cc:        serviceability-dev@openjdk.java.net

Date:        16/04/2018 07:10 
    Subject:        Re: RFR: 8201409: JDWP
  debugger initialization hangs intermittently 
 


On 4/15/18 10:01, Daniel D. Daugherty wrote: 
On 4

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-23 Thread serguei.spit...@oracle.com

On 4/23/18 16:08,
serguei.spit...@oracle.com wrote:

Hi Andrew,

There is a regression with this fix.
The following test is failed with timeout on all platforms
except Windows:

Sorry, forgot to copy the test name:
open/test/jdk/com/sun/jdi/JITDebug.sh

Thanks,
Serguei

I'll try to get more details about
this timeout.

Thanks,
Serguei

On 4/18/18 09:49, serguei.spit...@oracle.com wrote:

Hi Andrew,

Sorry, I did not reply earlier.
The fix need more testing. We also have some important tests
in closed.
I'll run them but I'm a little bit busy at the moment.

You have two reviews which is enough for push after testing.

Thanks,
Serguei

On 4/18/18 08:23, Andrew Leonard wrote:

Hi Serguei,
Do you need me to try anything else for this review?
hotspot/jtreg/serviceability suite run successfully.

Many Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com

From: "serguei.spit...@oracle.com" <serguei.spit...@oracle.com>

To: daniel.daughe...@oracle.com,
Andrew Leonard <andrew_m_leon...@uk.ibm.com>

Cc: serviceability-dev@openjdk.java.net

Date: 16/04/2018 07:10
Subject: Re: RFR: 8201409: JDWP
debugger initialization hangs intermittently

On 4/15/18 10:01, Daniel D. Daugherty wrote:
On 4/13/18 3:07 PM, serguei.spit...@oracle.com
wrote:
Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that
includes the bug number.

The issues is:
https://bugs.openjdk.java.net/browse/JDK-8201409

Webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
So now pauses in debugLoop_run() before the loop
that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
So the VM_INIT event handler now signals that we have
received the VM_INIT event so that allows
debugLoop_run()
to proceed.

Serguei, this fix needs to have the most of the
Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb
tests).
Based on the email thread, I can't tell which tests have
been
run with the fix in place.

Hi Dan,

I'm going to sponsor this fix and will run all the debugger
tests.
Sorry that I did not announce it yet.

Thanks,
Serguei

Dan

The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for
this issue is not easy.

At least, one more review is needed before the fix can be
pushed.

Thanks,
Serguei

On 4/11/18 06:33, Andrew Leonard wrote:
Hi Serguei,
Thank you for raising the bug.
I had a chat with one of my colleagues who could recreate
it, and it's probably related to the handshaking that is
done in the particular scenario. So with the JCK harness:

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-23 Thread serguei.spit...@oracle.com


  
  
Hi Andrew,
  
  There is a regression with this fix.
  The following test is failed with timeout on all platforms except
  Windows.
  I'll try to get more details about this timeout.
  
  Thanks,
  Serguei
  
  
  On 4/18/18 09:49, serguei.spit...@oracle.com wrote:


  
  Hi Andrew,

Sorry, I did not reply earlier.
The fix need more testing. We also have some important tests in
closed.
I'll run them but I'm a little bit busy at the moment.

You have two reviews which is enough for push after testing.

Thanks,
Serguei


On 4/18/18 08:23, Andrew Leonard wrote:
  
  
Hi Serguei, 
Do you need me to try anything else for this review?
  hotspot/jtreg/serviceability suite run successfully. 
Many Thanks 
Andrew 

Andrew Leonard
  Java Runtimes Development
  IBM Hursley
  IBM United Kingdom Ltd
  Phone internal: 245913, external: 01962 815913
  internet email: andrew_m_leon...@uk.ibm.com 





From:        "serguei.spit...@oracle.com" <serguei.spit...@oracle.com>

To:        daniel.daughe...@oracle.com,
  Andrew Leonard <andrew_m_leon...@uk.ibm.com>

Cc:        serviceability-dev@openjdk.java.net

Date:        16/04/2018 07:10 
        Subject:        Re: RFR: 8201409: JDWP
  debugger initialization hangs intermittently 
 


On 4/15/18 10:01, Daniel D. Daugherty wrote: 
On 4/13/18 3:07 PM, serguei.spit...@oracle.com
  wrote: 
Andrew and reviewers,
  
  I'm re-sending this RFR with a corrected subject that includes
  the bug number.
  
  The issues is:
    https://bugs.openjdk.java.net/browse/JDK-8201409
  
  Webrev:
    http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/

 
src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
    No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
    No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
    So now pauses in debugLoop_run() before the loop
    that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
    So the VM_INIT event handler now signals that we have
    received the VM_INIT event so that allows
debugLoop_run()
    to proceed.

Serguei, this fix needs to have the most of the
Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb
tests).
Based on the email thread, I can't tell which tests have
been
run with the fix in place. 

  Hi Dan,
  
  I'm going to sponsor this fix and will run all the debugger
  tests.
  Sorry that I did not announce it yet.
  
  Thanks,
  Serguei
 

Dan
   

  
  The fix looks good to me.
  Also, I've agreed to skip a unit test as creating it for this
  issue is not easy.
  
  At least, one more review is needed before the fix can be
  pushed.
  
  Thanks,
  Serguei
  
  
  On 4/11/18 06:33, Andrew Leonard wrote: 
Hi Serguei, 
  Thank you for raising the bug. 
  I had a chat with one of my colleagues who could recreate it,
  and it's probably related to the handshaking that is done in
  the particular scenario. So with the JCK harness: 
  
  com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck/jck8b/natives/linux_x86-64
  /projects/jck/jdwp/j2sdk-image/bin/java
  -Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache
  -Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache
  -Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache
  -Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache
  -Xfuture
  -agentlib:jdwp=server=y,transport=dt_socket,address=localhost:35000,suspend=y
  -classpath /javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/classes
  -Djava.security.policy=/javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/lib/jck.policy
  javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600
  -msgSwitch=ub1604x64vm10:38636 -componentName=ArrayReference.GetValues.getvalues002

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-19 Thread Andrew Leonard

No Problem, thanks Serguei, let me know if I can help in any way.
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   "serguei.spit...@oracle.com" <serguei.spit...@oracle.com>
To: Andrew Leonard <andrew_m_leon...@uk.ibm.com>
Cc: daniel.daughe...@oracle.com, serviceability-dev@openjdk.java.net
Date:   18/04/2018 17:56
Subject:    Re: RFR: 8201409: JDWP debugger initialization hangs 
intermittently



Hi Andrew,

Sorry, I did not reply earlier.
The fix need more testing. We also have some important tests in closed.
I'll run them but I'm a little bit busy at the moment.

You have two reviews which is enough for push after testing.

Thanks,
Serguei


On 4/18/18 08:23, Andrew Leonard wrote:
Hi Serguei, 
Do you need me to try anything else for this review? 
hotspot/jtreg/serviceability suite run successfully. 
Many Thanks 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:"serguei.spit...@oracle.com" <serguei.spit...@oracle.com> 
To:daniel.daughe...@oracle.com, Andrew Leonard 
<andrew_m_leon...@uk.ibm.com> 
Cc:serviceability-dev@openjdk.java.net 
Date:        16/04/2018 07:10 
Subject:Re: RFR: 8201409: JDWP debugger initialization hangs 
intermittently 



On 4/15/18 10:01, Daniel D. Daugherty wrote: 
On 4/13/18 3:07 PM, serguei.spit...@oracle.com wrote: 
Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that includes the bug 
number.

The issues is:
  https://bugs.openjdk.java.net/browse/JDK-8201409

Webrev:
  
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/ 

 
src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
So now pauses in debugLoop_run() before the loop
that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
So the VM_INIT event handler now signals that we have
received the VM_INIT event so that allows debugLoop_run()
to proceed.

Serguei, this fix needs to have the most of the Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb tests).
Based on the email thread, I can't tell which tests have been
run with the fix in place. 

Hi Dan,

I'm going to sponsor this fix and will run all the debugger tests.
Sorry that I did not announce it yet.

Thanks,
Serguei


Dan



The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for this issue is not 
easy.

At least, one more review is needed before the fix can be pushed.

Thanks,
Serguei


On 4/11/18 06:33, Andrew Leonard wrote: 
Hi Serguei, 
Thank you for raising the bug. 
I had a chat with one of my colleagues who could recreate it, and it's 
probably related to the handshaking that is done in the particular 
scenario. So with the JCK harness: 

com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck
/jck8b/natives/linux_x86-64 /projects/jck/jdwp/j2sdk-image/bin/java 
-Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache 
-Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache 
-Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache 
-Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache -
Xfuture -agentlib:jdwp=server=y,transport=dt_socket,address=localhost
:35000,suspend=y -classpath /javatest/lib/jck
/JCK8b-b03/JCK-runtime-8b/classes -Djava.security.policy=/javatest/lib/jck
/JCK8b-b03/JCK-runtime-8b/lib/jck.policy 
javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600 
-msgSwitch=ub1604x64vm10:38636 -componentName=
ArrayReference.GetValues.getvalues002 

Note that the JCK test harness starts the target process, attaches to it, 
and sends the resume command 
in a very short time with no handshaking. 

That may not help..but hopefully helps explain things a bit? It's the 
timing of the resume command during the test that is crucial, resuming 
before the VM initialization is complete will trigger it. 

Thanks 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:"serguei.spit...@oracle.com" <serguei.spit...@oracle.com> 
To:Andrew Leonard <andrew_m_leon...@uk.ibm.com> 
Cc:serviceability-dev@openjdk.java.net 
Date:11/04/2018 09:57 
Subject:Re: RFR: Fix race condition in jdwp 



Hi Andrew,

I've filed the bug:
  https://bugs.openjdk.java.net/browse/JDK-8201409

Also, this is a webrev with your patch:
  
http://cr.openjdk.java.net/~sspitsyn

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-18 Thread serguei.spit...@oracle.com

Hi Andrew,

Sorry, I did not reply earlier.
The fix need more testing. We also have some important tests in
closed.
I'll run them but I'm a little bit busy at the moment.

You have two reviews which is enough for push after testing.

Thanks,
Serguei

On 4/18/18 08:23, Andrew Leonard wrote:

Hi Serguei,

Do you need me
to try anything else for this review?
hotspot/jtreg/serviceability suite
run successfully.

Many Thanks

Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com

From:
"serguei.spit...@oracle.com"
<serguei.spit...@oracle.com>

To:
daniel.daughe...@oracle.com,
Andrew Leonard <andrew_m_leon...@uk.ibm.com>

Cc:
serviceability-dev@openjdk.java.net

Date:
16/04/2018
07:10

Subject:
Re:
RFR: 8201409: JDWP debugger initialization hangs intermittently

On 4/15/18 10:01, Daniel D. Daugherty
wrote:

On 4/13/18 3:07 PM, serguei.spit...@oracle.com
wrote:

Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that includes
the bug
number.

The issues is:
https://bugs.openjdk.java.net/browse/JDK-8201409

Webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
So now pauses in debugLoop_run() before the loop
that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
So the VM_INIT event handler now signals that we have
received the VM_INIT event so that allows debugLoop_run()
to proceed.

Serguei, this fix needs to have the most of the Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb
tests).
Based on the email thread, I can't tell which tests have been
run with the fix in place.

Hi Dan,

I'm going to sponsor this fix and will run all the debugger
tests.
Sorry that I did not announce it yet.

Thanks,
Serguei

Dan

The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for this
issue is
not easy.

At least, one more review is needed before the fix can be
pushed.

Thanks,
Serguei

On 4/11/18 06:33, Andrew Leonard wrote:

Hi Serguei,
Thank you for raising the bug.
I had a chat with one of my colleagues who could recreate it,
and it's
probably related to the handshaking that is done in the
particular scenario.
So with the JCK harness:

com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck/jck8b/natives/linux_x86-64
/projects/jck/jdwp/j2sdk-image/bin/java
-Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache
-Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache
-Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache
-Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache
-Xfuture
-agentlib:jdwp=server=y,transport=dt_socket,address=localhost:35000,suspend=y
-classpath /javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/classes
-Djava.security.policy=/javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/lib/jck.policy
javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600
-msgSwitch=ub1604x64vm10:38636
-componentName=ArrayReference.GetValues.getvalues002

Note that the JCK test harness starts the target process,
attaches to it,
and sends the resume command
in a very short time with no handshaking.

That may not help..but hopefully helps explain things a bit?
It's the timing
of the resume command during the test that is crucial, resuming
before
the VM initialization is

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-18 Thread Andrew Leonard

Hi Serguei,
Do you need me to try anything else for this review? 
hotspot/jtreg/serviceability suite run successfully.
Many Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   "serguei.spit...@oracle.com" <serguei.spit...@oracle.com>
To: daniel.daughe...@oracle.com, Andrew Leonard 
<andrew_m_leon...@uk.ibm.com>
Cc: serviceability-dev@openjdk.java.net
Date:   16/04/2018 07:10
Subject:    Re: RFR: 8201409: JDWP debugger initialization hangs 
intermittently



On 4/15/18 10:01, Daniel D. Daugherty wrote:
On 4/13/18 3:07 PM, serguei.spit...@oracle.com wrote:
Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that includes the bug 
number.

The issues is:
  https://bugs.openjdk.java.net/browse/JDK-8201409

Webrev:
  
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/
 
src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
So now pauses in debugLoop_run() before the loop
that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
So the VM_INIT event handler now signals that we have
received the VM_INIT event so that allows debugLoop_run()
to proceed.

Serguei, this fix needs to have the most of the Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb tests).
Based on the email thread, I can't tell which tests have been
run with the fix in place.

Hi Dan,

I'm going to sponsor this fix and will run all the debugger tests.
Sorry that I did not announce it yet.

Thanks,
Serguei


Dan



The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for this issue is not 
easy.

At least, one more review is needed before the fix can be pushed.

Thanks,
Serguei


On 4/11/18 06:33, Andrew Leonard wrote:
Hi Serguei, 
Thank you for raising the bug. 
I had a chat with one of my colleagues who could recreate it, and it's 
probably related to the handshaking that is done in the particular 
scenario. So with the JCK harness: 

com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck
/jck8b/natives/linux_x86-64 /projects/jck/jdwp/j2sdk-image/bin/java 
-Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache 
-Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache 
-Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache 
-Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache -
Xfuture -agentlib:jdwp=server=y,transport=dt_socket,address=localhost
:35000,suspend=y -classpath /javatest/lib/jck
/JCK8b-b03/JCK-runtime-8b/classes -Djava.security.policy=/javatest/lib/jck
/JCK8b-b03/JCK-runtime-8b/lib/jck.policy 
javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600 
-msgSwitch=ub1604x64vm10:38636 -componentName=
ArrayReference.GetValues.getvalues002 

Note that the JCK test harness starts the target process, attaches to it, 
and sends the resume command 
in a very short time with no handshaking. 

That may not help..but hopefully helps explain things a bit? It's the 
timing of the resume command during the test that is crucial, resuming 
before the VM initialization is complete will trigger it. 

Thanks 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:"serguei.spit...@oracle.com" <serguei.spit...@oracle.com> 
To:Andrew Leonard <andrew_m_leon...@uk.ibm.com> 
Cc:serviceability-dev@openjdk.java.net 
Date:11/04/2018 09:57 
Subject:Re: RFR: Fix race condition in jdwp 



Hi Andrew,

I've filed the bug:
  https://bugs.openjdk.java.net/browse/JDK-8201409

Also, this is a webrev with your patch:
  
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/


I agree that creating a standalone test is tricky here.

I've added usleep(1) into the eventHelper_reportVMInit()
and ran the JTreg com/sun/jdi tests with my JDK build.
However, none of the tests failed with the failure mode you described.
So that I'm puzzled a little bit.
I suspect that some specific debugLoop commands were used in your 
scenario.

It is still possible that I've missed something here.
Will try to double check everything.

Thanks,
Serguei


On 4/11/18 01:29, Andrew Leonard wrote: 
Thanks Serguei, 
I terms of a standalone testcase it is quite tricky, as due to the nature 
of the issue which took a lot of investigation to solve it's very timing 
dependent and will only occur randomly. It can be forced as I indicated 
below by adding a "sleep" in the VMInit report code but that's not a 
testcase, however the issue

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-16 Thread Andrew Leonard

Hi Daniel,
Thanks for reviewing this. Just to let you know, I have successfully run 
all the jdk_core and hotspot/jtreg/serviceability tests with this patch in 
place.
Cheers
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   "Daniel D. Daugherty" <daniel.daughe...@oracle.com>
To: "serguei.spit...@oracle.com" <serguei.spit...@oracle.com>, Andrew 
Leonard <andrew_m_leon...@uk.ibm.com>
Cc: serviceability-dev@openjdk.java.net
Date:   15/04/2018 18:00
Subject:    Re: RFR: 8201409: JDWP debugger initialization hangs 
intermittently



On 4/13/18 3:07 PM, serguei.spit...@oracle.com wrote:
Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that includes the bug 
number.

The issues is:
  https://bugs.openjdk.java.net/browse/JDK-8201409

Webrev:
  
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/
 
src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
So now pauses in debugLoop_run() before the loop
that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
So the VM_INIT event handler now signals that we have
received the VM_INIT event so that allows debugLoop_run()
to proceed.

Serguei, this fix needs to have the most of the Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb tests).
Based on the email thread, I can't tell which tests have been
run with the fix in place.

Dan



The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for this issue is not 
easy.

At least, one more review is needed before the fix can be pushed.

Thanks,
Serguei


On 4/11/18 06:33, Andrew Leonard wrote:
Hi Serguei, 
Thank you for raising the bug. 
I had a chat with one of my colleagues who could recreate it, and it's 
probably related to the handshaking that is done in the particular 
scenario. So with the JCK harness: 

com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck
/jck8b/natives/linux_x86-64 /projects/jck/jdwp/j2sdk-image/bin/java 
-Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache 
-Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache 
-Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache 
-Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache -
Xfuture -agentlib:jdwp=server=y,transport=dt_socket,address=localhost
:35000,suspend=y -classpath /javatest/lib/jck
/JCK8b-b03/JCK-runtime-8b/classes -Djava.security.policy=/javatest/lib/jck
/JCK8b-b03/JCK-runtime-8b/lib/jck.policy 
javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600 
-msgSwitch=ub1604x64vm10:38636 -componentName=
ArrayReference.GetValues.getvalues002 

Note that the JCK test harness starts the target process, attaches to it, 
and sends the resume command 
in a very short time with no handshaking. 

That may not help..but hopefully helps explain things a bit? It's the 
timing of the resume command during the test that is crucial, resuming 
before the VM initialization is complete will trigger it. 

Thanks 
Andrew 

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:"serguei.spit...@oracle.com" <serguei.spit...@oracle.com> 
To:Andrew Leonard <andrew_m_leon...@uk.ibm.com> 
Cc:serviceability-dev@openjdk.java.net 
Date:11/04/2018 09:57 
Subject:Re: RFR: Fix race condition in jdwp 



Hi Andrew,

I've filed the bug:
  https://bugs.openjdk.java.net/browse/JDK-8201409

Also, this is a webrev with your patch:
  
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/


I agree that creating a standalone test is tricky here.

I've added usleep(1) into the eventHelper_reportVMInit()
and ran the JTreg com/sun/jdi tests with my JDK build.
However, none of the tests failed with the failure mode you described.
So that I'm puzzled a little bit.
I suspect that some specific debugLoop commands were used in your 
scenario.

It is still possible that I've missed something here.
Will try to double check everything.

Thanks,
Serguei


On 4/11/18 01:29, Andrew Leonard wrote: 
Thanks Serguei, 
I terms of a standalone testcase it is quite tricky, as due to the nature 
of the issue which took a lot of investigation to solve it's very timing 
dependent and will only occur randomly. It can be forced as I indicated 
below by adding a "sleep" in the VMInit report code but that's not a 
testcase, however the issue was originally found in our JCK testing for 
IBMJava8, testcase test.jck8b.runtime.vm.jdwp, but again

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-16 Thread serguei.spit...@oracle.com

On 4/15/18 10:01, Daniel D. Daugherty
wrote:

On 4/13/18 3:07 PM, serguei.spit...@oracle.com
wrote:

Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that
includes the bug number.

The issues is:
https://bugs.openjdk.java.net/browse/JDK-8201409

Webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
So now pauses in debugLoop_run() before the loop
that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
So the VM_INIT event handler now signals that we have
received the VM_INIT event so that allows debugLoop_run()
to proceed.

Serguei, this fix needs to have the most of the Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb tests).
Based on the email thread, I can't tell which tests have been
run with the fix in place.

Hi Dan,

I'm going to sponsor this fix and will run all the debugger tests.
Sorry that I did not announce it yet.

Thanks,
Serguei

Dan

The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for this
issue is not easy.

At least, one more review is needed before the fix can be
pushed.

Thanks,
Serguei

On 4/11/18 06:33, Andrew Leonard wrote:

Hi Serguei,
Thank you for raising the bug.
I had a chat with one of my colleagues who could
recreate it, and it's probably related to the handshaking
that is done in the particular scenario. So with the JCK
harness:

com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck/jck8b/natives/linux_x86-64
/projects/jck/jdwp/j2sdk-image/bin/java
-Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache
-Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache
-Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache
-Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache
-Xfuture
-agentlib:jdwp=server=y,transport=dt_socket,address=localhost:35000,suspend=y
-classpath /javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/classes
-Djava.security.policy=/javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/lib/jck.policy
javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600
-msgSwitch=ub1604x64vm10:38636 -componentName=ArrayReference.GetValues.getvalues002

Note that the JCK test harness starts the target
process, attaches to it, and sends the resume command

in a very short time with no handshaking.

That may not help..but hopefully helps explain things a
bit? It's the timing of the resume command during the test
that is crucial, resuming before the VM initialization is
complete will trigger it.

Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com

From: "serguei.spit...@oracle.com"

To: Andrew Leonard

Cc: serviceability-dev@openjdk.java.net

Date: 11/04/2018 09:57
Subject: Re: RFR: Fix race condition
in jdwp

Hi Andrew,

I've filed the bug:
https://bugs.openjdk.java.net/browse/JDK-8201409

Also, this is a webrev with your patch:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/

I agree that creating a standalone test is tricky here.

I've added usleep(1) into the eventHelper_reportVMInit()
and ran the JTreg com/sun/jdi tests with my JDK build.
However, none of

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

2018-04-15 Thread Daniel D. Daugherty


On 4/13/18 3:07 PM, serguei.spit...@oracle.com wrote:

Andrew and reviewers,

I'm re-sending this RFR with a corrected subject that includes the bug 
number.


The issues is:
_https://bugs.openjdk.java.net/browse/JDK-8201409_ 



Webrev:
_http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/_ 



src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
    No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.h
    No comments.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
    So now pauses in debugLoop_run() before the loop
    that reads cmds. Looks good.

src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
    So the VM_INIT event handler now signals that we have
    received the VM_INIT event so that allows debugLoop_run()
    to proceed.

Serguei, this fix needs to have the most of the Serviceability
stack of tests run against it (jdwp, JVM/TI, JDI and jdb tests).
Based on the email thread, I can't tell which tests have been
run with the fix in place.

Dan




The fix looks good to me.
Also, I've agreed to skip a unit test as creating it for this issue is 
not easy.


At least, one more review is needed before the fix can be pushed.

Thanks,
Serguei


On 4/11/18 06:33, Andrew Leonard wrote:

Hi Serguei,
Thank you for raising the bug.
I had a chat with one of my colleagues who could recreate it, and 
it's probably related to the handshaking that is done in the 
particular scenario. So with the JCK harness:


com.sun.jck.lib.ExecJCKTestOtherJVMCmd 
LD_LIBRARY_PATH=/_javatest_/_lib_/_jck_/jck8b/natives/linux_x86-64 
/projects/_jck_/jdwp/j2sdk-image/bin/java -Xdump:system:none 
-Xdump:system:events=_gpf_+abort+_traceassert_+_corruptcache_ 
-Xdump:snap:none 
-Xdump:snap:events=_gpf_+abort+_traceassert_+_corruptcache_ 
-Xdump:java:none 
-Xdump:java:events=_gpf_+abort+_traceassert_+_corruptcache_ 
-Xdump:heap:none 
-Xdump:heap:events=_gpf_+abort+_traceassert_+_corruptcache_ 
-_Xfuture_ 
-agentlib:jdwp=server=y,transport=dt_socket,address=_localhost_:35000,suspend=y 
-_classpath_ /_javatest_/_lib_/_jck_/JCK8b-b03/JCK-runtime-8b/classes 
-Djava.security.policy=/_javatest_/_lib_/_jck_/JCK8b-b03/JCK-runtime-8b/_lib_/jck.policy 
javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -_waittime_=600 
-msgSwitch=ub1604x64vm10:38636 
-componentName=*ArrayReference.GetValues.getvalues002*


Note that the JCK test harness starts the target process, attaches to 
it, and sends the resume command

in a very short time with no handshaking.

That may not help..but hopefully helps explain things a bit? It's the 
timing of the resume command during the test that is crucial, 
resuming before the VM initialization is complete will trigger it.


Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com




From: "serguei.spit...@oracle.com" 
To: Andrew Leonard 
Cc: serviceability-dev@openjdk.java.net
Date: 11/04/2018 09:57
Subject: Re: RFR: Fix race condition in jdwp




Hi Andrew,

I've filed the bug:
_https://bugs.openjdk.java.net/browse/JDK-8201409_ 



Also, this is a webrev with your patch:
_http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/_ 



I agree that creating a standalone test is tricky here.

I've added usleep(1) into the eventHelper_reportVMInit()
and ran the JTreg com/sun/jdi tests with my JDK build.
However, none of the tests failed with the failure mode you described.
So that I'm puzzled a little bit.
I suspect that some specific debugLoop commands were used in your 
scenario.


It is still possible that I've missed something here.
Will try to double check everything.

Thanks,
Serguei


On 4/11/18 01:29, Andrew

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

Re: RFR: 8201409: JDWP debugger initialization hangs intermittently

12 matches

Site Navigation

Mail list logo

Footer information