Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8331487

Can't find bundle for base name sun.util.resources.cldr.TimeZoneNames, locale en

    XMLWordPrintable

Details

    • generic
    • generic

    Description

      A DESCRIPTION OF THE PROBLEM :
      Under rare circumstances JVM throws  java.util.MissingResourceException: Can't find bundle for base name sun.util.resources.cldr.TimeZoneNames, locale en_US and the same message appears in the date line of JInfo System properties. 
      20240405.162119 Caused by: java.util.MissingResourceException: Can't find bundle for base name sun.util.resources.cldr.TimeZoneNames, locale en_US
      20240405.162119 at java.base/sun.util.resources.Bundles.throwMissingResourceException(Bundles.java:302)
      20240405.162119 at java.base/sun.util.resources.Bundles.loadBundleOf(Bundles.java:147)
      20240405.162119 at java.base/sun.util.resources.Bundles.of(Bundles.java:106)
      20240405.162119 at java.base/sun.util.resources.LocaleData$1.run(LocaleData.java:186)
      20240405.162119 at java.base/sun.util.resources.LocaleData$1.run(LocaleData.java:183)
      20240405.162119 at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
      20240405.162119 at java.base/sun.util.resources.LocaleData.getBundle(LocaleData.java:183)
      20240405.162119 at java.base/sun.util.resources.LocaleData.getTimeZoneNames(LocaleData.java:114)
      20240405.162119 at java.base/sun.util.locale.provider.LocaleResources.getTimeZoneNames(LocaleResources.java:280)
      20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameProviderImpl.getDisplayNameArray(TimeZoneNameProviderImpl.java:127)
      20240405.162119 at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.getDisplayNameArray(CLDRTimeZoneNameProviderImpl.java:75)
      20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameProviderImpl.getDisplayName(TimeZoneNameProviderImpl.java:99)
      20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getName(TimeZoneNameUtility.java:271)
      20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:229)
      20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:215)
      20240405.162119 at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:275)
      20240405.162119 at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:236)
      20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197)
      20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayName(TimeZoneNameUtility.java:150)
      20240405.162119 at java.base/java.util.TimeZone.getDisplayName(TimeZone.java:402)
      20240405.162119 at java.base/java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1306)
      20240405.162119 at java.base/java.text.SimpleDateFormat.format(SimpleDateFormat.java:1001)
      20240405.162119 at java.base/java.text.SimpleDateFormat.format(SimpleDateFormat.java:971)
      20240405.162119 at java.base/java.text.DateFormat.format(DateFormat.java:378)
      ...
      I don't have a reliable reproducer, but this looks like a race condition between JVM startup and external invocation of JInfo command. Heapdump had an  unreachable Bundles$CacheKey that had cause NPE with the following backtrace:Type|Name|Value
      ---------------------------------------------------------------------------------------------
      ref |[0] |class java.util.Objects @ 0x7bf808858
      ref |[1] |class java.lang.Class @ 0x7bf800d88
      ref |[2] |class sun.util.resources.Bundles @ 0x7bf070120
      ref |[3] |class sun.util.resources.Bundles @ 0x7bf070120
      ref |[4] |class sun.util.resources.Bundles @ 0x7bf070120
      ref |[5] |class sun.util.resources.Bundles @ 0x7bf070120
      ref |[6] |class sun.util.resources.Bundles @ 0x7bf070120
      ref |[7] |class sun.util.resources.LocaleData$1 @ 0x7bf06fd98
      ref |[8] |class sun.util.resources.LocaleData$1 @ 0x7bf06fd98
      ref |[9] |class java.security.AccessController @ 0x7bf801578
      ref |[10]|class sun.util.resources.LocaleData @ 0x7bf06f9a0
      ref |[11]|class sun.util.resources.LocaleData @ 0x7bf06f9a0
      ref |[12]|class sun.util.locale.provider.LocaleResources @ 0x7bf06f470
      ref |[13]|class sun.util.locale.provider.TimeZoneNameProviderImpl @ 0x7bf068040
      ref |[14]|class sun.util.cldr.CLDRTimeZoneNameProviderImpl @ 0x7bf0680c8
      ref |[15]|class sun.util.locale.provider.TimeZoneNameProviderImpl @ 0x7bf068040
      ref |[16]|class sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter @ 0x7bf040f08
      ref |[17]|class sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter @ 0x7bf040f08
      ref |[18]|class sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter @ 0x7bf040f08
      ref |[19]|class sun.util.locale.provider.LocaleServiceProviderPool @ 0x7bf0407e0
      ref |[20]|class sun.util.locale.provider.LocaleServiceProviderPool @ 0x7bf0407e0
      ref |[21]|class sun.util.locale.provider.TimeZoneNameUtility @ 0x7bf0405b8
      ref |[22]|class sun.util.locale.provider.TimeZoneNameUtility @ 0x7bf0405b8
      ref |[23]|class java.util.TimeZone @ 0x7bf00de70
      ref |[24]|class java.util.Date @ 0x7bf00ce90
      ref |[25]|class java.util.Properties @ 0x7bf8023b8
      ref |[26]|class java.util.Properties @ 0x7bf8023b8
      ref |[27]|class jdk.internal.vm.VMSupport @ 0x7bf000800
      ref |[28]|class jdk.internal.vm.VMSupport @ 0x7bf000800
      ---------------------------------------------------------------------------------------------
      Jinfo tries to print the current date for system properties and gets NPE from VMSupport->Properties-> new Date() -> ... ->Bundles->Class->Objects.  I didn't deconstruct NPE backtrace, but is it possible that the Bundles.module at this stage is still null and it results in caching Bundles$CacheKey with NPE cause?

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      This looks very timing related, I couldn't reproduce it with a simple main, but could trigger it by running Tomcat restarts and Jinfo on process in the loop. It happened mostly on VMs with just 4 cores and 24g xmx/xms with AlwaysPreTouch. We've encountered it just a few times on different hardware configurations. In general it happens on ~ 0.01% of restarts, but with this hardware setup it was >1% of restarts.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      No exceptions thrown in application and successful Jinfo invocation
      ACTUAL -
      Jinfo doesn't print System properties and application throws java.util.MissingResourceException: Can't find bundle for base name sun.util.resources.cldr.TimeZoneNames, locale en_US

      CUSTOMER SUBMITTED WORKAROUND :
      Couldn't reproduce an error after postponing Jinfo invocation.


      FREQUENCY : rarely


      Attachments

        Activity

          People

            naoto Naoto Sato
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated: