Hi Phil,
I confirmed WFontConfiguration::findFontWithCharset cannot find if
-Dfile.encoding=UTF-8 is passed.
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.
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.
I can share minidump for further investigation. What should I do / share?
Thanks,
Yasumasa
On 2020/07/28 0:02, Philip Race wrote:
Hi,
You're avoiding a crash but I don't yet know what *exactly* caused the crash.
Some Java code not handling DEFAULT_CHARSET is obviously not the exact cause.
This just starts it and something bad presumably happens later in native code.
And I don't yet understand why (we think) this started happening when some
additional fonts were added to the file.
Knowing exactly what is wrong will help decide if this is the right fix.
-phil
On 7/24/20, 5:59 AM, Yasumasa Suenaga wrote:
Hi Jay,
I share you hs_err log of this issue.
`chcp` on my console shows "932" (MS932). It is Japanese locale.
I can share you if you want to know.
Thanks,
Yasumasa
On 2020/07/24 20:59, Jayathirth D V wrote:
Hi Yasumasa,
I tried after changing the locale to Japanese but I don’t see the issue.
Also tried to reproduce the issue by enabling/disabling setting "Beta:Use Unicode
UTF-8 for worldwide language support" in my locale setting.
@Others : Can somebody else try to reproduce this issue?
Thanks,
Jay
-----Original Message-----
From: Yasumasa Suenaga <suen...@oss.nttdata.com>
Sent: Thursday, July 23, 2020 5:41 PM
To: Jayathirth D v <jayathirth....@oracle.com>
Cc: 2d-dev <2d-dev@openjdk.java.net>; awt-...@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed
with -Dfile.encoding=UTF-8
Hi Jay,
On 2020/07/23 19:09, Jayathirth D v wrote:
Hi,
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.
Am I missing something?
OS locale may be affecting.
My laptop has been set Japanese (CP932 / Windows-31J), so WFontConfiguration
attempt to find Japanese font by default.
However WFontConfiguration cannot find out the font of "DEFAULT_CHARSET" when
-Dfile.encoding=UTF-8 is passed.
Thanks,
Yasumasa
Also I think this should be in awt-dev so adding the mailing list.
Thanks,
Jay
On 20-Jul-2020, at 12:59 PM, Yasumasa Suenaga <suen...@oss.nttdata.com> wrote:
PING: could you review it?
JBS: https://bugs.openjdk.java.net/browse/JDK-8249215
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/
Yasumasa
On 2020/07/11 17:39, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8249215
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/
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.
I investigated it, then I found out current implementation cannot handle
default charset.
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.
This change has passed all tests on submit repo
(mach5-one-ysuenaga-JDK-8249215-20200711-0655-12566039)
Thanks,
Yasumasa
