JDK-8136497 : vm/mlvm/anonloader/func/invalidSuperclass fails on windows
  • Type: Bug
  • Component: core-libs
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Incomplete
  • OS: windows
  • Submitted: 2015-09-14
  • Updated: 2021-07-28
  • Resolved: 2016-05-23
Related Reports
Duplicate :  
JDK-8136499 - vm/mlvm/anonloader/func/invalidSuperclass fails on windows
Relates :  
JDK-8139390 - Very long classname in jimage causes SIGSEGV
Relates :  
JDK-8087181 - Move native jimage code to its own library (maybe libjimage)
Description
The said test started failing exclusively on windows both 32 and 64 bit. 
The failures are probably cause by a change between 
a589f73b79f4 and 41b6cb9246fe. We pulled down a bunch of changes from the main repo, these have to be checked for the possible cause. 

ILW = LMH = P4
Comments
Not reproducible, not seen recently and not enough information to fix.
23-05-2016
Is this one still an issue? The jimage code has gone through a number of iterations since this bug was created.
23-04-2016
Roger I will be unavailable for several weeks. You wrote the core of this code, will you take a look?
14-10-2015
Hi, The test vm/mlvm/anonloader/func/invalidSuperclass fails because of the fix for JDK-8087181. As JDK-8087181 affects targets the core-libs/runtime component, this is not a compiler issue. Please find supporting evidence below. The failure started to appear: - on Thursday, 2015-09-10 in the nightly testing of hs-main; - on Friday, 2015-09-11 in the nightly testing of hs-comp. On every Thursday, team repositories are synced with hs-main. The failure is *not caused* by hs-comp changes, because the test was executed and passed hs-comp nightly testing on the days before the sync (2015-09-10 and earlier). The failure started to appear in the hs-comp and hs-main nightly testing once changes from other reporitories (e.g., hs-rt) were pushed to hs-comp/hs-main. Therefore the failure must be caused by changeset(s) in those repositories. I started investigating the changesets in hs-rt before the sync happened (2015-09-10 and earlier). Note that the failing test is executed in neither in GC nightly testing nor in Runtime nightly testing. I executed the failing test with all builds used in Runtime nightly testing from 2015-08-31 and 2015-09-10. The failure starts appearing with the build used on 2015-09-04. That makes the following changesets likely candidates for the failure: 8087181: Move native jimage code to its own library (maybe libjimage)... (jlaskey, 2015-09-04 10:12:08) 8130823: VerifyRememberedSets is an expensive nop in product builds... (jwilhelm, 2015-09-04 13:23:10) 8135012: Don't use G1RootProcessor when scanning remembered sets... (mgerdin, 2015-09-04 09:47:35) 8134857: Inconsistency in maximum TLAB/PLAB size and humongous object size... (tschatzl, 2015-09-04 08:36:13) I executed the failing test with the build used to push each changeset. The test passes for all builds except the build used to push JDK-8087181. Therefore, it seems that JDK-8087181 is causing the test to fail. Therefore, I'm changing the component of the current issue to core-libs and assign it to Jim Laskey (Jim is the author of JDK-8087181 that was filed agains the component core-libs). Please feel free to update those fields with more approriate values. Thank you and best regards, Zoltan
01-10-2015