TL JDK 7 build 38 - strange failures
Tim Bell
Tim.Bell at Sun.COM
Mon Oct 13 11:57:36 PDT 2008
CC: sent to serviceability-dev for general distribution
Hi Kumar:
Thanks for looking into these issues.
> The cause for 6758616 failure is the Serial UID has been changes,
> this is not a launcher issue, I also verified by copying the
> TL's rt.jar into a stock b37 promoted build (which has the old launcher and
> passed the test) and now the test fails.
>
> I have updated the bug with the following comments:
>
> "As the error suggests the schema of the class has changed, the test seems
> to be trying to redefine the class java/lang/InterruptedException.
> This appears to be the case with the fix for 6749308, which has
> changed the SerialUID of various exceptions and errors, and
> java/lang/InterruptedException is one of them, and a CCC
> request has been filed http://ccc.sfbay/6749308, therefore it appears
> that the test needs to be readjusted."
So 6758616 is a test bug, correct?
> Tim: I filed a new bug 6758881 for the NoClassDefFoundError exception of
> the
> launcher, I think its best to fix this before we push, I will complete
> the code changes
> test and send it out to review tmr, I should be able to push by
> tomorrow PM.
> Please let me know how I should go about it.
Thanks - For 6758881, once you have your reviews, send me a pointer
to your webrev. I can pull the changes and create a changeset on
your behalf in my merge workspace. After that I will respin builds
and make them available for testing and verification.
Tim
> Thanks
> Kumar
>
>> btw, it would be good to have new bits with fixed NoClassDefFoundError
>> so we can test it.
>> but probably after you look at 6758616 ...
>>
>> Ekaterina Pavlova wrote:
>>> Thanks Kumar.
>>>
>>> I have filed
>>> 6758616 Redefinition of InterruptedException failed with
>>> JVMTI_ERROR_UNSUPPORTED_REDEFINITION_SCHEMA_CHANGED
>>> java/java/serviceability
>>> I am not sure the category is proper because I am not sure what
>>> changes caused this regression.
>>> So, feel free to change the category if needed.
>>>
>>> -katya
>>>
>>> Kumar Srinivasan wrote:
>>>> Katya,
>>>>
>>>> Ok I have a fix for the Exception ie, it will throw the
>>>> NoClassDefFoundError,
>>>> instead of JavaRuntimeException.
>>>>
>>>> After making this change, ran runnsk (from the location below), I
>>>> see only the
>>>> attach002 unexpected failure. If you can file a bug, I will get this
>>>> reviewed and
>>>> work with Tim to get this into the push repo.
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>> % $ALT_OUTPUTDIR/bin/java Foo
>>>> Error: Could not find main class Foo
>>>> Exception in thread "main" java.lang.NoClassDefFoundError: Foo
>>>> at
>>>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:193)
>>>> Caused by: java.lang.ClassNotFoundException: Foo
>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:220)
>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:209)
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:208)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
>>>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
>>>> at
>>>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:190)
>>>>> btw: are these tests that you are running the nsk tests ?
>>>>>
>>>>> If so, is this accurate ? /java/svc/tools/bin/runnsk
>>>>>
>>>>> The reason I ask is there are more launcher changes coming up.
>>>>> I would like to catch issues earlier on in the development cycle.
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>>
>>>>>
>>>>>> Tim,
>>>>>>
>>>>>> if we have time I would prefer to postpone the integration till
>>>>>> next week.
>>>>>> Is it ok?
>>>>>>
>>>>>> -katya
>>>>>>
>>>>>> Tim Bell wrote:
>>>>>>> Kumar Srinivasan wrote:
>>>>>>>> I am not sure why the RedefineClasses test is failing.
>>>>>>>> If the expected NoClassDefFoundError is required
>>>>>>>> i can look into throwing that exception. I don't think
>>>>>>>> that warrants a no-go.
>>>>>>>
>>>>>>> Katya - are you OK with this explanation?
>>>>>>>
>>>>>>> Will you be able to issue a Serviceability PIT certificate today
>>>>>>> (Friday)?
>>>>>>>
>>>>>>> Or, do you feel this is a stopper, in which case we can wait and
>>>>>>> iron out the issues next week.
>>>>>>>
>>>>>>> Please let me know what to expect so I can plan the rest of my day-
>>>>>>>
>>>>>>> Thanks-
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Kumar
>>>>>>>>
>>>>>>>>> <including Dan in case he has to look at the RedefineClasses
>>>>>>>>> test failing>
>>>>>>>>>
>>>>>>>>> But Katya has what looks like two valid tests failing:
>>>>>>>>>> I am seeing strange failures in jdk7b38 TL pit.
>>>>>>>>>> One of them is that java doesn't throw "NoClassDefFoundError"
>>>>>>>>>> when trying to load non existing class.
>>>>>>>>>>
>>>>>>>>>> For example:
>>>>>>>>>> >
>>>>>>>>>> /net/sqenfs-1.sfbay/export1/comp/vm/jdk/7/pit/b38/solaris-sparc/bin/java
>>>>>>>>>> ops
>>>>>>>>>> Error: Could not find main class ops
>>>>>>>>>> Exception in thread "main" java.lang.RuntimeException: Could
>>>>>>>>>> not find the main class ops
>>>>>>>>>> at
>>>>>>>>>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:193)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Before it was:
>>>>>>>>>> >
>>>>>>>>>> /java/re/jdk/7/promoted/all/b37/binaries/solaris-sparc/bin/java
>>>>>>>>>> ops
>>>>>>>>>> Exception in thread "main" java.lang.NoClassDefFoundError: ops
>>>>>>>>>> Caused by: java.lang.ClassNotFoundException: ops
>>>>>>>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:220)
>>>>>>>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:209)
>>>>>>>>>> at java.security.AccessController.doPrivileged(Native
>>>>>>>>>> Method)
>>>>>>>>>> at
>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:208)
>>>>>>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
>>>>>>>>>> at
>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>>>>>>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
>>>>>>>>>> at
>>>>>>>>>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:338)
>>>>>>>>>> Error: Could not find the main class ops.
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>>> one more failure is in nsk/jvmti/AttachOnDemand/attach002a.
>>>>>>>>>> It fails on all platforms with
>>>>>>>>>> # error occured while redefining
>>>>>>>>>> JVMTI_ERROR_UNSUPPORTED_REDEFINITION_SCHEMA_CHANGED
>>>>>>>>>> # ERROR: attach002aAgent00.c, 48:
>>>>>>>>>> nsk_jvmti_aod_redefineClass(options, jvmti, object_class,
>>>>>>>>>> REDEFINED_CLASS_FILE_NAME)
>>>>>>>>>>
>>>>>>>>>> See full log here:
>>>>>>>>>> http://sqeweb.sfbay.sun.com/nfs/comp/vm/misc/results/vm/gtee/JDK7/PIT/CORE/SERVICEABILITY/7/b38/vm/solaris-amd64/server/mixed/solaris-amd64_server_mixed_nsk.jvmti.testlist/ResultDir/attach002a/attach002a.log
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The test passes with jdk7-b37.
>>>>>>>>>>
>>>>>>>>>> I am going to file new bugs but I am also thinking if we
>>>>>>>>>> should give no-go for this PIT ...
>>>>>>>>> So it looks like something is wrong with your change.
>>>>>>>>> - jjh
>>>>>>>>>
>>>>>>>>> Kumar Srinivasan wrote:
>>>>>>>>>> Hi Jim. et. al.,
>>>>>>>>>>
>>>>>>>>>> Yes from a time line the applications main-class
>>>>>>>>>> is loader a bit earlier than before, with one JNI upcall vs.
>>>>>>>>>> 3-4.
>>>>>>>>>>
>>>>>>>>>> The class loading is slightly different with the new launcher.
>>>>>>>>>>
>>>>>>>>>> The big improvements are the application class loading is
>>>>>>>>>> pushed into
>>>>>>>>>> java and and the boot classes need by the launcher are fetched
>>>>>>>>>> from the VMs BCP (katya, this is related to the other HotSpot fix
>>>>>>>>>> which you refered to earlier this week) loader directly vs.
>>>>>>>>>> going through
>>>>>>>>>> the application class loader, this improves startup performance.
>>>>>>>>>>
>>>>>>>>>> Pushing the application class loading to java gives us better
>>>>>>>>>> control of diagnosing user problems and reporting the issues
>>>>>>>>>> with user friendly and localized messages. A classic example
>>>>>>>>>> is the one cited below, the new message is neat and clean vs. a
>>>>>>>>>> terse and unfriendly message scary message. Also its considerably
>>>>>>>>>> less native code in the launcher (which is a "good thing!").
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Kumar
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ekaterina Pavlova wrote:
>>>>>>>>>>>> may be these 2 bugs caused the changes ...
>>>>>>>>>>>> 6742159 java tools (launcher) improve the java
>>>>>>>>>>>> launching mechanism
>>>>>>>>>>>> 6755847 java tools (launcher) will trigger
>>>>>>>>>>>> assertions in debug buil
>>>>>>>>>>>>
>>>>>>>>>>> These do look like likely candidates. Kumar, what do you think?
>>>>>>>>>>> - jjh
>>>>>>>>>>>> Jim Holmlund wrote:
>>>>>>>>>>>>> I wonder if this is related to that issue I sent earlier:
>>>>>>>>>>>>>> Per previous email, this change causes VM test
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn002
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to fail. It appears to me that the test makes an invalid
>>>>>>>>>>>>>> assumption about when a class is loaded, and with this new
>>>>>>>>>>>>>> TL, the class is loaded at a point earlier than the point
>>>>>>>>>>>>>> at which it is loaded in previous JDK builds/releases. If
>>>>>>>>>>>>>> this is true, then the new TL isn't wrong, just
>>>>>>>>>>>>>> different. But I wonder if this difference could have any
>>>>>>>>>>>>>> other negative impacts?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - jjh
>>>>>>>>>>>>> 'this change' means the TL pit. I looked thru the list
>>>>>>>>>>>>> of CRs below and doen't see a likely culprit.
>>>>>>>>>>>>> Chris, what about:
>>>>>>>>>>>>> 6749308 java.io, java.lang, java.util exception
>>>>>>>>>>>>> classes don't specify serialVersionUID
>>>>>>>>>>>>> - jjh
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ekaterina Pavlova wrote:
>>>>>>>>>>>>>> thanks Jim.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Btw, Jim, Tim,
>>>>>>>>>>>>>> I am seeing strange failures in jdk7b38 TL pit.
>>>>>>>>>>>>>> One of them is that java doesn't throw
>>>>>>>>>>>>>> "NoClassDefFoundError" when trying to load non existing
>>>>>>>>>>>>>> class.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For example:
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> /net/sqenfs-1.sfbay/export1/comp/vm/jdk/7/pit/b38/solaris-sparc/bin/java
>>>>>>>>>>>>>> ops
>>>>>>>>>>>>>> Error: Could not find main class ops
>>>>>>>>>>>>>> Exception in thread "main" java.lang.RuntimeException:
>>>>>>>>>>>>>> Could not find the main class ops
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:193)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Before it was:
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> /java/re/jdk/7/promoted/all/b37/binaries/solaris-sparc/bin/java
>>>>>>>>>>>>>> ops
>>>>>>>>>>>>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>>>>>>>>>>>>> ops
>>>>>>>>>>>>>> Caused by: java.lang.ClassNotFoundException: ops
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:220)
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> java.net.URLClassLoader$1.run(URLClassLoader.java:209)
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:208)
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:325)
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:270)
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:338)
>>>>>>>>>>>>>> Error: Could not find the main class ops.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> something is wrong with this build.
>>>>>>>>>>>>>> Do you know what changes result in such behavior?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jim Holmlund wrote:
>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/jdk/test/com/sun/jdi/SimulResumerTest.java
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I added that to the CR also. Sorry about that.
>>>>>>>>>>>>>>> - jjh
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ekaterina Pavlova wrote:
>>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> what tests could be used to verify:
>>>>>>>>>>>>>>>> 6751643 java debugger
>>>>>>>>>>>>>>>> ThreadReference.ownedMonitors() can return null
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>>> -katya
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tim Bell wrote:
>>>>>>>>>>>>>>>>> Webrevs: http://lonepeak.sfbay/PIT/b38/Agones-MASTER
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> PIT builds done by JPRT job ID
>>>>>>>>>>>>>>>>> 2008-10-07-051427.tbell.Agones
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> executable bits (nightly build number 281)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/linux-i586
>>>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/linux-x64
>>>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/solaris-i586
>>>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/solaris-sparc
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/solaris-sparcv9
>>>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/solaris-x64
>>>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/windows-i586
>>>>>>>>>>>>>>>>> /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/windows-x64
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tests:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Under /net/bonsai.sfbay/w/builds/jdk/7/pit/b38/
>>>>>>>>>>>>>>>>> jdk/test
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> langtools/test
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> bundles:
>>>>>>>>>>>>>>>>> are in
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /net/jprt-web.sfbay/jprt/archive/2008/10/2008-10-07-051427.tbell.Agones/bundles
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> linux_i586_2.4-product.zip
>>>>>>>>>>>>>>>>> linux_x64_2.4-product.zip
>>>>>>>>>>>>>>>>> solaris_i586_5.10-product.zip
>>>>>>>>>>>>>>>>> solaris_sparc_5.10-product.zip
>>>>>>>>>>>>>>>>> solaris_sparcv9_5.10-product.zip
>>>>>>>>>>>>>>>>> solaris_x64_5.10-product.zip
>>>>>>>>>>>>>>>>> windows_i586_5-product.zip
>>>>>>>>>>>>>>>>> windows_x64_5.2-product.zip
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please issue PIT certificates (or PIT waivers) for the
>>>>>>>>>>>>>>>>> following areas
>>>>>>>>>>>>>>>>> by noon (Pacific) on Friday the 10th of October (or
>>>>>>>>>>>>>>>>> sooner if
>>>>>>>>>>>>>>>>> possible). Our putback slot is PM on Friday. Please CC:
>>>>>>>>>>>>>>>>> tl-integrators at sfbay.sun.com when sending certificates.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Security: YES
>>>>>>>>>>>>>>>>> Networking: YES
>>>>>>>>>>>>>>>>> Core Libraries: YES
>>>>>>>>>>>>>>>>> Tools: YES
>>>>>>>>>>>>>>>>> JMX: YES
>>>>>>>>>>>>>>>>> jconsole: NO
>>>>>>>>>>>>>>>>> Serviceability: YES
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> security/pit and networking/docs/pit/ jobs are in the
>>>>>>>>>>>>>>>>> process of
>>>>>>>>>>>>>>>>> submitting themselves now.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In this round, we have:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 6749308 java classes_lang java.io, java.lang,
>>>>>>>>>>>>>>>>> java.util exception classes
>>>>>>>>>>>>>>>>> 6621697 java classes_net Problem with file
>>>>>>>>>>>>>>>>> test/sun/net/www/http/ChunkedI
>>>>>>>>>>>>>>>>> 6739920 java classes_net java 6u4~ use larger C heap
>>>>>>>>>>>>>>>>> if there are many th
>>>>>>>>>>>>>>>>> 6746836 java classes_net java.net exception classes
>>>>>>>>>>>>>>>>> don't specify serialV
>>>>>>>>>>>>>>>>> 6750364 java classes_net Error in test for 6744329
>>>>>>>>>>>>>>>>> 6752807 java classes_net java.net test
>>>>>>>>>>>>>>>>> ADatagramSocket.sh is broken
>>>>>>>>>>>>>>>>> 6469266 java classes_secu Integrate Apache XMLSec
>>>>>>>>>>>>>>>>> 1.4.2 into JDK 7
>>>>>>>>>>>>>>>>> 6420151 java compiler need to improve byfile
>>>>>>>>>>>>>>>>> compile policy to elimina
>>>>>>>>>>>>>>>>> 6500343 java compiler compiler generates bad code
>>>>>>>>>>>>>>>>> when translating con
>>>>>>>>>>>>>>>>> 6735840 java compiler Need a type/symbol visitor
>>>>>>>>>>>>>>>>> printer
>>>>>>>>>>>>>>>>> 6739427 java compiler -Xlint:processing not
>>>>>>>>>>>>>>>>> recognized as an option
>>>>>>>>>>>>>>>>> 6747671 java compiler -Xlint:rawtypes
>>>>>>>>>>>>>>>>> 6753718 java compiler raw type warnings should be
>>>>>>>>>>>>>>>>> suprresed during a l
>>>>>>>>>>>>>>>>> 6751643 java debugger
>>>>>>>>>>>>>>>>> ThreadReference.ownedMonitors() can return null
>>>>>>>>>>>>>>>>> 6748546 java javadoctool javadoc API should be
>>>>>>>>>>>>>>>>> classloader-friendly
>>>>>>>>>>>>>>>>> 6748601 java javadoctool javadoc API should allow
>>>>>>>>>>>>>>>>> varargs use
>>>>>>>>>>>>>>>>> 6581243 java sunserviceta Service Tag and Product
>>>>>>>>>>>>>>>>> Registration Support in
>>>>>>>>>>>>>>>>> 4459600 java tools java -jar fails to run
>>>>>>>>>>>>>>>>> Main-Class if classname f
>>>>>>>>>>>>>>>>> 6742159 java tools (launcher) improve the java
>>>>>>>>>>>>>>>>> launching mechanism
>>>>>>>>>>>>>>>>> 6755847 java tools (launcher) will trigger
>>>>>>>>>>>>>>>>> assertions in debug buil
>>>>>>>>>>>>>>>>> 6750935 jmx classes The expected
>>>>>>>>>>>>>>>>> NotCompliantMBeanException is not t
>>>>>>>>>>>>>>>>> 6751872 jmx doc MXBeanMappingFactory example
>>>>>>>>>>>>>>>>> says "implements" w
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
More information about the serviceability-dev
mailing list