<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    This did start when we updated the fontconfiguration file but I
    think there was nothing wrong with the update<br>
    and I found it could happen with the previous  version if we just
    remove "devanagari" from this line in the OLD version.<br>
    <br>
sequence.allfonts.UTF-8.ja=alphabetic,japanese,devanagari,dingbats,symbol<br>
    <br>
    Removing that mimics what happened in the new version and is the
    first piece of the puzzle.<br>
    <br>
    I don't know why devanagari is even there. Possibly it is because
    that line was derived from this one :-<br>
sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol<br>
    since hindi was the first UTF-8 locale that was supported and
    someone just edited it to create the JA entry.<br>
    <br>
    But it indicates to me that this is quite fragile and could easily
    have crashed a long time ago if Devanagari were<br>
    not there as one of the "core fonts" for UTF-8.ja<br>
    <br>
    Then in WFontConfiguration.initTables() a few things happen<br>
    <br>
    first this <br>
    <pre style="background-color:#ffffff;color:#080808;font-family:'JetBrains Mono',monospace;font-size:9.8pt;">subsetCharsetMap.put(<span style="color:#067d17;">"devanagari"</span>, <span style="color:#067d17;">"DEFAULT_CHARSET"</span>);
subsetCharsetMap.put(<span style="color:#067d17;">"japanese"</span>, <span style="color:#067d17;">"SHIFTJIS_CHARSET"</span>);

[for devanagari JDK specifies the Mangal font.]

the subsetEncodinging map has this for Japanese
 subsetEncodingMap.put("japanese", "windows-31j");

then this for UTF-8 for textInputCharset
} <span style="color:#0033b3;">else if </span>(<span style="color:#067d17;">"UTF-8"</span>.equals(defaultEncoding)) {
    textInputCharset = <span style="color:#067d17;">"DEFAULT_CHARSET"</span>;

whereas for the old ms932/windows-31j code page we would have had this

} <span style="color:#0033b3;">else if </span>(<span style="color:#067d17;">"windows-31j"</span>.equals(defaultEncoding)) {
    textInputCharset = <span style="color:#067d17;">"SHIFTJIS_CHARSET"</span>;

it then calls makeAWTFontName("MS Gothic", "japanese");
which looks like this :

WFontConfiguration.makeAWTFontName(String platformFontName, String characterSubsetName) {
    String windowsCharset = subsetCharsetMap.get(characterSubsetName);
    <span style="color:#0033b3;">if </span>(windowsCharset == <span style="color:#0033b3;">null</span>) {
        windowsCharset = <span style="color:#067d17;">"DEFAULT_CHARSET"</span>;
    }
    <span style="color:#0033b3;">return </span>platformFontName + <span style="color:#067d17;">"," </span>+ windowsCharset;
}

For "japanese", the result of 
subsetCharsetMap.get(characterSubsetName);

will always be <span style="color:#067d17;">"SHIFTJIS_CHARSET"</span>

So the method will return "MS Gothic,SHIFTJIS_CHARSET"
and this will get stored in the FontDescriptor

The other core entries for Japanese map to ANSI_CHARSET and SYMBOL_CHARSET.

When in the old fontconfig file  is called for "devanagari", it will return "Mangal,DEFAULT_CHARSET".

Without that, there is no DEFAULT_CHARSET mapped for any font in the core Japanese fonts.

This all becomes important when WFontConfiguration.getTextComponentFontName() is called from native code.

It has this line
String fontName = findFontWithCharset(fontDescriptors, textInputCharset);

from above we know that for UTF-8 :
    textInputCharset = <span style="color:#067d17;">"DEFAULT_CHARSET"</span>;

but as just noted above there are NO fonts tagged with that 

So the look up fails. The code retries : -
<span style="color:#0033b3;">if </span>(fontName == <span style="color:#0033b3;">null</span>) {
    fontName = findFontWithCharset(fontDescriptors, <span style="color:#067d17;">"DEFAULT_CHARSET"</span>);
}
 
but that was pointless since DEFAULT_CHARSET is what was already tried.

Now back to the windows-31j locale, there we had 

    textInputCharset = <span style="color:#067d17;">"SHIFTJIS_CHARSET"</span>;

so that finds the match "MS Gothic,SHIFTJIS_CHARSET".

 getTextComponentFontName() has the comment "<span style="color:#8c8c8c;font-style:italic;">May return null."

</span><span style="color:#8c8c8c;font-style:italic;"></span>which is true, but not very helpful to the native caller, which bails out, leaving the
native font structs uninitialised and ready to cause a crash.

That's the kind of analysis I was hoping for !

Now, the question is, is what you propose the right fix for this ?
But I am not sure it can even work.

<span style="display: inline !important; float: none; background-color: rgb(238, 238, 238); color: blue; font-family: Consolas; font-size: 13.33px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: pre; word-spacing: 0px;"> 931             descriptors[i] = new FontDescriptor(awtFontName, enc, exclusionRanges, encoding.equals("default"));

<font color="#000000">seems like it will never pass true in my testing. Then the whole fix falls apart.

Can you show some evidence ?

-phil</font></span></pre>
    <br>
    <br>
    <div class="moz-cite-prefix">On 7/27/2020 3:50 PM, Yasumasa Suenaga
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:8a5a1d0f-7396-b086-b97d-1eafb251600a@oss.nttdata.com">Hi
      Phil,
      <br>
      <br>
      I confirmed WFontConfiguration::findFontWithCharset cannot find if
      -Dfile.encoding=UTF-8 is passed.
      <br>
      I guess one of the cause is the definitions in
      make/data/fontconfig/windows.fontconfig.properties, but also
      DEFAULT_CHARSET does not work at this point.
      <br>
      <br>
      If we do not pass -Dfile.encoding=UTF-8, `charset` in
      WFontConfiguration::findFontWithCharset is set to "windows-31j"
      and it can find out valid font when Windows is set to Japanese
      locale.
      <br>
      <br>
      I can share minidump for further investigation. What should I do /
      share?
      <br>
      <br>
      <br>
      Thanks,
      <br>
      <br>
      Yasumasa
      <br>
      <br>
      <br>
      On 2020/07/28 0:02, Philip Race wrote:
      <br>
      <blockquote type="cite">Hi,
        <br>
        <br>
        You're avoiding a crash but I don't yet know what *exactly*
        caused the crash.
        <br>
        Some Java code not handling DEFAULT_CHARSET is obviously not the
        exact cause.
        <br>
        This just starts it and something bad presumably happens later
        in native code.
        <br>
        <br>
        And I don't yet understand why (we think) this started happening
        when some
        <br>
        additional fonts were added to the file.
        <br>
        <br>
        Knowing exactly what is wrong will help decide if this is the
        right fix.
        <br>
        <br>
        -phil
        <br>
        <br>
        On 7/24/20, 5:59 AM, Yasumasa Suenaga wrote:
        <br>
        <blockquote type="cite">Hi Jay,
          <br>
          <br>
          I share you hs_err log of this issue.
          <br>
          `chcp` on my console shows "932" (MS932). It is Japanese
          locale.
          <br>
          <br>
          I can share you if you want to know.
          <br>
          <br>
          <br>
          Thanks,
          <br>
          <br>
          Yasumasa
          <br>
          <br>
          <br>
          On 2020/07/24 20:59, Jayathirth D V wrote:
          <br>
          <blockquote type="cite">Hi Yasumasa,
            <br>
            <br>
            I tried after changing the locale to Japanese but I don’t
            see the issue.
            <br>
            <br>
            Also tried to reproduce the issue by enabling/disabling
            setting "Beta:Use Unicode UTF-8 for worldwide language
            support" in my locale setting.
            <br>
            <br>
            @Others : Can somebody else try to reproduce this issue?
            <br>
            <br>
            Thanks,
            <br>
            Jay
            <br>
            <br>
            -----Original Message-----
            <br>
            From: Yasumasa Suenaga <a class="moz-txt-link-rfc2396E" href="mailto:suenaga@oss.nttdata.com"><suenaga@oss.nttdata.com></a>
            <br>
            Sent: Thursday, July 23, 2020 5:41 PM
            <br>
            To: Jayathirth D v <a class="moz-txt-link-rfc2396E" href="mailto:jayathirth.d.v@oracle.com"><jayathirth.d.v@oracle.com></a>
            <br>
            Cc: 2d-dev <a class="moz-txt-link-rfc2396E" href="mailto:2d-dev@openjdk.java.net"><2d-dev@openjdk.java.net></a>;
            <a class="moz-txt-link-abbreviated" href="mailto:awt-dev@openjdk.java.net">awt-dev@openjdk.java.net</a>
            <br>
            Subject: Re: [OpenJDK 2D-Dev] PING: RFR: 8249215:
            JFrame::setVisible crashed with -Dfile.encoding=UTF-8
            <br>
            <br>
            Hi Jay,
            <br>
            <br>
            On 2020/07/23 19:09, Jayathirth D v wrote:
            <br>
            <blockquote type="cite">Hi,
              <br>
              <br>
              I tried reproducing the issue in my Windows 10 machine
              with UTF-8 encoding and test file mentioned in the bug, I
              don’t see any crash.
              <br>
              Am I missing something?
              <br>
            </blockquote>
            <br>
            OS locale may be affecting.
            <br>
            <br>
            My laptop has been set Japanese (CP932 / Windows-31J), so
            WFontConfiguration attempt to find Japanese font by default.
            <br>
            However WFontConfiguration cannot find out the font of
            "DEFAULT_CHARSET" when -Dfile.encoding=UTF-8 is passed.
            <br>
            <br>
            <br>
            Thanks,
            <br>
            <br>
            Yasumasa
            <br>
            <br>
            <br>
            <blockquote type="cite">Also I think this should be in
              awt-dev so adding the mailing list.
              <br>
              <br>
              Thanks,
              <br>
              Jay
              <br>
              <br>
              <blockquote type="cite">On 20-Jul-2020, at 12:59 PM,
                Yasumasa Suenaga <a class="moz-txt-link-rfc2396E" href="mailto:suenaga@oss.nttdata.com"><suenaga@oss.nttdata.com></a> wrote:
                <br>
                <br>
                PING: could you review it?
                <br>
                <br>
                <blockquote type="cite">    JBS:
                  <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8249215">https://bugs.openjdk.java.net/browse/JDK-8249215</a>
                  <br>
                      webrev:
                  <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/">http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/</a>
                  <br>
                </blockquote>
                <br>
                Yasumasa
                <br>
                <br>
                On 2020/07/11 17:39, Yasumasa Suenaga wrote:
                <br>
                <blockquote type="cite">Hi all,
                  <br>
                  Please review this change:
                  <br>
                      JBS:
                  <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8249215">https://bugs.openjdk.java.net/browse/JDK-8249215</a>
                  <br>
                      webrev:
                  <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/">http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/</a>
                  <br>
                  I tried to run Sample.java in JDK-8236161 with
                  -Dfile.encoding=UTF-8, but JVM crashed due to internal
                  error on fastdebug VM. I saw same call stack with
                  JDK-8236161 in hs_err log.
                  <br>
                  I investigated it, then I found out current
                  implementation cannot handle default charset.
                  <br>
                  If charset is set to UTF-8, it would be handled as
                  "DEFAULT_CHARSET" in WFontConfiguration::initTables.
                  However it does not affect native font name, so we
                  cannot find valid font.
                  <br>
                  This change has passed all tests on submit repo
                  (mach5-one-ysuenaga-JDK-8249215-20200711-0655-12566039)
                  <br>
                  Thanks,
                  <br>
                  Yasumasa
                  <br>
                </blockquote>
              </blockquote>
              <br>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>