JDK-8062938 : [TEST_BUG] sun/jvmstat/monitor/MonitoredVm/CR6672135.java: java.lang.IllegalArgumentException: Could not map vmid to user name
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 8u101,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-11-05
  • Updated: 2023-11-30
  • Resolved: 2015-07-27
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 9
9 b77Fixed
Related Reports
Duplicate :  
JDK-8064572 - sun/jvmstat/monitor/MonitoredVm/CR6672135.java: java.lang.IllegalArgumentException: Process not found
Relates :  
JDK-8130636 - sun/tools/jcmd/TestJcmdSanity.java sun.jvmstat.monitor.MonitorException failure
Relates :  
JDK-8064572 - sun/jvmstat/monitor/MonitoredVm/CR6672135.java: java.lang.IllegalArgumentException: Process not found
Relates :  
JDK-8036616 - [TESTBUG] Embedded: sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be launched with -XX:+UsePerfData
Sub Tasks
JDK-8064343 :  
sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be quarantined - Resolved
Description
Platform: Windows Server 2008 6.0 (x86)
Platform: Linux 2.6.39-300.20.1.el6uek.x86_64 (amd64)

#section:main
----------messages:(3/150)----------
command: main -XX:+UsePerfData CR6672135
reason: User specified action: run main/othervm -XX:+UsePerfData CR6672135 
elapsed time (seconds): 1.705
----------System.out:(0/0)----------
----------System.err:(26/1525)----------
java.lang.Error: Test failed
	at CR6672135.main(CR6672135.java:60)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:745)
Caused by: sun.jvmstat.monitor.MonitorException: 14836 not found
	at sun.jvmstat.perfdata.monitor.protocol.local.PerfDataBuffer.<init>(PerfDataBuffer.java:84)
	at sun.jvmstat.perfdata.monitor.protocol.local.LocalMonitoredVm.<init>(LocalMonitoredVm.java:68)
	at sun.jvmstat.perfdata.monitor.protocol.local.MonitoredHostProvider.getMonitoredVm(MonitoredHostProvider.java:77)
	at sun.jvmstat.perfdata.monitor.protocol.local.MonitoredHostProvider.getMonitoredVm(MonitoredHostProvider.java:67)
	at CR6672135.main(CR6672135.java:53)
	... 6 more
Caused by: java.lang.IllegalArgumentException: Could not map vmid to user name
	at sun.misc.Perf.attach(Native Method)
	at sun.misc.Perf.attachImpl(Perf.java:270)
	at sun.misc.Perf.attach(Perf.java:200)
	at sun.jvmstat.perfdata.monitor.protocol.local.PerfDataBuffer.<init>(PerfDataBuffer.java:64)
	... 10 more

JavaTest Message: Test threw exception: java.lang.Error: Test failed
JavaTest Message: shutting down test



RULE sun/jvmstat/monitor/MonitoredVm/CR6672135.java Exception java.lang.IllegalArgumentException: Could not map vmid to user name
RULE sun/jvmstat/monitor/MonitoredVm/CR6672135.java Exception java.lang.IllegalArgumentException: Could not map vmid to user Name
Comments
It doesn't seem worth it, since this is just a P4 testbug. I closed the backport
27-06-2016
shshahma@slc09vmu:/scratch/shshahma/Java/jdk9-dev$ find ./ -name LingeredApp.java ./test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java In jdk9 the above java file is present where as in jdk8 this is not there. shshahma@slc09vmu:/scratch/shshahma/Java/jdk8u-dev$ find ./ -name LingeredApp.java shshahma@slc09vmu:/scratch/shshahma/Java/jdk8u-dev$ Code changes has reference of the class 'LingeredApp' defined in file LingeredApp.java as shown below. In fact library path '/test/lib/share/classes' doesn't exists in jdk8 repo. //test/sun/jvmstat/monitor/MonitoredVm/TestPollingInterval.java . . . 30 import jdk.testlibrary.Utils; 31 import jdk.test.lib.apps.LingeredApp; 32 import sun.jvmstat.monitor.MonitorException; . . . 44 * @library /lib/testlibrary 45 * @library /test/lib/share/classes I did some search in bugs.openjdk.java.net and found there are few bugs for which we did some changes in this file. https://bugs.openjdk.java.net/browse/JDK-8081037 => file LingeredApp.java added [http://hg.openjdk.java.net/jdk9/jdk9/rev/609627f9db3f] https://bugs.openjdk.java.net/browse/JDK-8086134 => Change in above file https://bugs.openjdk.java.net/browse/JDK-8081576 => Change in above file To backport this we have to backport all the dependent changes.
27-06-2016
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b394674d44d1 User: lana Date: 2015-08-11 20:21:52 +0000
11-08-2015
URL: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/b394674d44d1 User: ykantser Date: 2015-07-27 13:28:11 +0000
27-07-2015
ILW=M (sometimes jvmstat fails in tests) L (intermittent) M (restart jvmstat) = P4
23-07-2015
My theory is that this test finds all VMs running on the machine, but some of those are not accessible to it - perhaps even running under a different user.
07-11-2014
This failure mode is not new but seems to have been wrongly ascribed to a different problem - see JDK-8033104
07-11-2014
I did some experimentation on my local windows system running the test without jtreg (which I don't have). I modified the test to process all the VMs it found and I couldn't produce an error. So bottom line is that I have no idea why the test fails the way it does.
07-11-2014
It is curious that no other test seems to test this functionality (but this is jvmstat): Set vms = localHost.activeVms(); Integer vmInt = (Integer) vms.iterator().next(); but I suspect the bug is in assuming that either there is only one VM active, or that the VM of interest will always be the first one returned by the Set iterator.
07-11-2014
Checking further, on linux there are two VMs regardless of whether /othervm is used. Can't test on wiindows.
05-11-2014
This test was just updated to run with /othervm -XX:+UsePerfData - the fix was "backported" from the SE embedded forests where it has been used for months - see 8036616. Looking at the test it seems to assume only a single VM will be present on the system - where now there will be two. Whether the test passes or fails seems to be determined by the order in which the available VMs are returned. On linux the test always passes. On windows it seems to fail.
05-11-2014