[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out
From:       Chris Plummer <chris.plummer () oracle ! com>
Date:       2018-11-30 3:06:55
Message-ID: 91711760-f8fa-5316-38e4-f487dc20bf11 () oracle ! com
[Download RAW message or body]

Ok. So this is when you attach using a main classname rather than a pid. 
We could probably make this test use a pid instead, but that doesn't 
actually fix the real issue.

Chris

On 11/29/18 6:12 PM, Daniil Titov wrote:
> Hi Chris,
> 
> It attaches to the instrumentation buffer when it is getting a MonitoredVm object \
> inside check() method at \
> jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java:85. It needs a \
> monitored VM to retrieve a main class name ( line 86) and use it on lines 100 and \
> 104  to filter out processes that don't match. 
> private static boolean check(VirtualMachineDescriptor vmd, String excludeClass, \
> String partialMatch) { 81	        String mainClass = null;
> 82	        try {
> 83	            VmIdentifier vmId = new VmIdentifier(vmd.id());
> 84	            MonitoredHost monitoredHost = MonitoredHost.getMonitoredHost(vmId);
> 85	            MonitoredVm monitoredVm = monitoredHost.getMonitoredVm(vmId, -1);
> 86	            mainClass = MonitoredVmUtil.mainClass(monitoredVm, true);
> 87	            monitoredHost.detach(monitoredVm);
> 88	        } catch (NullPointerException npe) {
> 89	            // There is a potential race, where a running java app is being
> 90	            // queried, unfortunately the java app has shutdown after this
> 91	            // method is started but before getMonitoredVM is called.
> 92	            // If this is the case, then the /tmp/hsperfdata_xxx/pid file
> 93	            // will have disappeared and we will get a NullPointerException.
> 94	            // Handle this gracefully....
> 95	            return false;
> 96	        } catch (MonitorException | URISyntaxException e) {
> 97	            return false;
> 98	        }
> 99	
> 100	        if (excludeClass != null && mainClass.equals(excludeClass)) {
> 101	            return false;
> 102	        }
> 103	
> 104	        if (partialMatch != null && mainClass.indexOf(partialMatch) == -1) {
> 105	            return false;
> 106	        }
> 107	
> 108	        return true;
> 109	    }
> 
> Below is the stack trace for that:
> attach:-1, Perf (jdk.internal.perf)
> attachImpl:270, Perf (jdk.internal.perf)
> attach:200, Perf (jdk.internal.perf)
> <init>:64, PerfDataBuffer (sun.jvmstat.perfdata.monitor.protocol.local)
> <init>:68, LocalMonitoredVm (sun.jvmstat.perfdata.monitor.protocol.local)
> getMonitoredVm:77, MonitoredHostProvider \
> (sun.jvmstat.perfdata.monitor.protocol.local) check:85, ProcessArgumentMatcher \
> (sun.tools.common) getVMDs:129, ProcessArgumentMatcher (sun.tools.common)
> getVirtualMachinePids:154, ProcessArgumentMatcher (sun.tools.common)
> main:83, JCmd (sun.tools.jcmd)
> 
> Best regards,
> Daniil
> 
> On 11/29/18, 5:16 PM, "Chris Plummer" <chris.plummer@oracle.com> wrote:
> 
> Can you remind me why the test is trying to attach to all running java
> processes.
> 
> Chris
> 
> On 11/29/18 1:30 PM, Daniil Titov wrote:
> > Thank you, David!
> > 
> > The proposed fix didn't help. It still hangs at some occasions.  Additional \
> > tracing showed that when jcmd is invoked with the main class name it iterates \
> > over all running Java processes and temporary attaches to them to retrieve the \
> > main class name. It hangs while trying to attach to one of the running Java \
> > processes. There are numerous Java processes running at the host machine some \
> > associated with the test framework itself and another with the tests running in \
> > parallel. It is not clear what exact is this particular process since the jcmd \
> > hangs before retrieving the process' main class name, but after all tests \
> > terminated the process with this id is no longer running.  I have to revoke this \
> > review since more investigation is required. 
> > 
> > Best regards,
> > Daniil
> > 
> > 
> > 
> > On 11/11/18, 1:35 PM, "David Holmes" <david.holmes@oracle.com> wrote:
> > 
> > Hi Daniil,
> > 
> > I took a quick look at this one ... two minor comments
> > 
> > The static class names could just be "Process" as they will acquire the
> > enclosing class name as part of their own name anyway. As it is this
> > gets repeated eg:
> > 
> > HelpTest$HelpTestProcess
> > InvalidCommandTest$InvalidCommandTestProcess
> > 
> > TestJavaProcess.java:
> > 
> > 39     public static void main(String argv[]) {
> > 
> > Nit: Should be "String[] argv" in Java style
> > 
> > Thanks,
> > David
> > 
> > On 10/11/2018 3:18 PM, Daniil Titov wrote:
> > > Please review the change that fixes serviceability/dcmd/framework/* tests from \
> > > a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests \
> > > non-concurrent to ensure that they don't interact with each other and there are \
> > > no multiple tests running simultaneously since all they do share the common \
> > > main class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks \
> > > like the  tests from other directories still might run in parallel with these \
> > > tests and they also have com.sun.javatest.regtest.agent.MainWrapper as a main \
> > > class. 
> > > The fix  ensures that each serviceability/dcmd/framework/* test uses a Java \
> > > process with a unique main class name when connecting to this process with jcmd \
> > > and the main class name. 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654
> > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/
> > > 
> > > Best regards,
> > > Daniil
> > > 
> > > 
> > 
> > 
> > 
> 
> 
> 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]