Community
Participate
Working Groups
Steps To Reproduce: 1. In Windows XP, start the 4.4.1 AC with security off. 2. From the command line, in enabled mode, profile the attached test case classes with 4.4.1 JVMTI profiling agent using either Sun or IBM 1.5. 2. Attach to the agent in Eclipse. 3. Once the agent is attached in Eclipse, hit enter on the command line. The exception below is thrown by the application (on the command line), and the program terminates. Reproduceable with IBM and Sun JDK. Running class without profiler = Works. 4403 Eclipse + 4403 AC + 4403 profiler = Works. 4403 Eclipse + 4403 AC + 441 profiler = Fails (as below) 441 Eclipse + 441 AC + 441 Profiler = Fails (as below) Implies a JVMTI profiling agent bug. Until we know the scope of the bug I've set severity to critical; upgrade or downgrade as desired. Exception: java.util.MissingResourceException: Can't find bundle for base name sun.text.resources.DateFormatZoneData, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:853) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:813) at java.util.ResourceBundle.getBundle(ResourceBundle.java:593) at sun.text.resources.LocaleData$1.run(LocaleData.java:137) at java.security.AccessController.doPrivileged(AccessController.java:197) at sun.text.resources.LocaleData.getBundle(LocaleData.java:135) at sun.text.resources.LocaleData.getDateFormatZoneData(LocaleData.java:131) at java.text.DateFormatSymbols.cacheLookup(DateFormatSymbols.java:436) at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:486) at java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:115) at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:470) at sun.net.www.protocol.file.FileURLConnection.initializeHeaders(FileURLConnection.java:128) at sun.net.www.protocol.file.FileURLConnection.getContentLength(FileURLConnection.java:151) at sun.misc.URLClassPath$Loader$1.getContentLength(URLClassPath.java:771) at sun.misc.Resource.getBytes(Resource.java:109) at java.net.URLClassLoader.defineClass(URLClassLoader.java:571) at java.net.URLClassLoader.access$400(URLClassLoader.java:123) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1034) at java.security.AccessController.doPrivileged(AccessController.java:279) at java.net.URLClassLoader.findClass(URLClassLoader.java:491) at java.lang.ClassLoader.loadClass(ClassLoader.java:629) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:328) at java.lang.ClassLoader.loadClass(ClassLoader.java:595) at HeapJniCarTest.<init>(HeapJniCarTest.java:27) at HeapJniCarTest.main(HeapJniCarTest.java:45)
Created attachment 88804 [details] Heap JNI Car Test Classes Source for these classes is available from CVS: HEAD/test-results/platform/org.eclipse.tptp.ac.testautomation/automation-files/external_classes/ Main class is HeapJniCarTest (And yes, despite the name of test, no JNI is used ;) )
I was able to reproduce this bug with IBM 1.5 SR6. I WAS NOT able to reproduce this with a Sun JVM. The IBM 1.5 SR6 exceptions are a known issue. Please see bug >>> comment >>> for more information. Jonathan: please enable the JVMTI Profiler logging (see below), try to reproduce this bug using a Sun JVM and if you succeed, post the log file here. To enable logging, define the following environment variables prior to launching the Java application: set MARTINI_LOGGER_DIRECTORY=<full path to an existing directory> set MARTINI_LOGGER_LOG_LEVEL=5 Thanks, Asaf
Oops... forgot the fill-in Bugzilla details.... Lets try again: I was able to reproduce this bug with IBM 1.5 SR6. I WAS NOT able to reproduce this with a Sun JVM. The IBM 1.5 SR6 exceptions are a known issue. Please see bug 215437 comment 4 for more information. Jonathan: please enable the JVMTI Profiler logging (see below), try to reproduce this bug using a Sun JVM and if you succeed, post the log file here. To enable logging, define the following environment variables prior to launching the Java application: set MARTINI_LOGGER_DIRECTORY=<full path to an existing directory> set MARTINI_LOGGER_LOG_LEVEL=5 Thanks, Asaf
> Reproduceable with IBM and Sun JDK. > > Running class without profiler = Works. > 4403 Eclipse + 4403 AC + 4403 profiler = Works. > 4403 Eclipse + 4403 AC + 441 profiler = Fails (as below) > 441 Eclipse + 441 AC + 441 Profiler = Fails (as below) Jonathan, could you confirm that you can reproduce this issue with SUN JVM. Please post output for "java.exe -version" Thanks, Alex
Hi Alex, Yes, I can confirm that I am unable to reproduce with a Sun JVM. Also of note, with the IBM JDK, the problem occurs only with HeapProf; CGProf does not cause the problem.
Created attachment 89106 [details] Patch Attached patch excludes these additional classes from HeapProf: java.security.* java.awt.* javax.swing.* com.ibm.jvm.* com.ibm.misc.* com.ibm.oti.* sun.security.* sun.misc.* sun.awt.* sun.java2d.* Notes: 1. This list pretty much covers the entire set of classes the IBM 1.5 JRE loads before it is fully initialized (i.e., before the JVMTI VMStart event fires). This list is excluded *regardless* of the JVM type, so it will also affect non-IBM JREs. The implication is that HeapProf will not track object allocations within these classes. 2. The patch solves this bug, and also solves similar problems encountered when profiling (using HeapProf) the Java2D JDK Demo application 3. We believe that there is a VM bug here that IBM needs to pursue. Patching out classes only masks the problem. We have only patched the classes that have shown up in testing. There may well be other classes with a similar fault that we are not currently aware of.
Alex, Joanna, Please let me know whether this fix is sufficient for 4.4.1. I will the use the formal channels to request approval and check-in the patch. Thanks, Asaf
*** Bug 217361 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Alex, Joanna, > Please let me know whether this fix is sufficient for 4.4.1. I will the use the > formal channels to request approval and check-in the patch. > > Thanks, > Asaf > I agree with approach and don't have objections about commit.
Patch checked-in to 4.4.1 branch.
Patch checked-in to 4.5 (HEAD) branch
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
