JDK-8187772 : JVM crash when currency set on MacOS 10.10 and earlier
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2017-09-21
  • Updated: 2017-12-16
  • Resolved: 2017-10-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b28Fixed
Related Reports
Relates :  
JDK-8188819 - Host locale adapter should honor currency overrides
Relates :  
JDK-8160199 - Language's script should be reflected in user.script on Mac OS X
Description
Java is crashing on command java --version itself.

OS Details:
ProductName: Mac OS X
ProductVersion: 10.10.5
BuildVersion:14F2109

Steps to reproduce:
Install or unzip jdk-10 binary(tested with build 22, 23, 24)
run java --version

Error Message(Attached full error log):
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fff8164a380, pid=55488, tid=3591
#
# JRE version:  (10.0+24) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10-ea+24, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [libsystem_platform.dylib+0x1380]  _platform_memmove$VARIANT$Nehalem+0x40
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.

Regression Details:
JDK9 build 181 - PASS
JDK10 build 22,23,24- Failed

Reproduciblity:
Reproducible consistently in one machine.
I couldn't reproduce any other machine.
Comments
From Sherman: My mac build fails / crashes for a while at exactly the same location. However my osx is 10.11.5/OSX El Capitan, and in my case the locale variable looks like "en-US@calendar=iso8601". It's not the currency, but the calendar is attached after "@"
12-10-2017
I have reproduced the crash on a MacOS 10.9 machine that I have. The test machine in question has a custom currency selected in the Language & Region control panel (Russian Ruble - RUB), which leads to the following failure mode (see java.base/macosx/native/libjava/java_props_macosx.c): In getMacOSXLocale(), we first get the primary language into 'languageString'. Versions of MacOS after 10.10 always return a region along with the language (e.g. "en-US"). But 10.10 and earlier often return just a two-letter language code ("en"), in which case we fetch the locale identifier from CFLocaleGetIdentifier() to look for the region. With the currency setting, the locale identifier includes a non-standard currency for en_US, "en_US@currency=RUB". This is a longer locale identifier than expected. The two-character language code in languageString is appended with '-', plus everything following the '_' in the locale identifier. Thus, "en-US@currency=RUB" is passed as the 'src' argument into convertToPosixLocale(). We expect the portion of 'src' following '-' to contain a script, a region, or both ('scriptRegion'). We check for a 2nd '-' (indicating that both a region and a script are present, e.g. "zh-Hans-US" or "zh-Hans-419"): char* region = strchr(scriptRegion + 1, '-'); There isn't one, nor is there a '_' : ... if (region == NULL) { // CFLocaleGetIdentifier() returns '_' before region region = strchr(scriptRegion + 1, '_'); } ... so region remains NULL. In the (length > 5) branch of the code, 'scriptRegion' is long enough that we expect it to contain both a script and a region. Therefore, two '-' characters, therefore region would have been set above. But the extra length of the currency string put us into this branch with a null region, so we SEGV on: memmove(scriptRegion + 1, region + 1, regionLength); ============ One workaround would be to set the machine's currency back to Dollars.
04-10-2017
According to link: http://www.oracle.com/technetwork/java/javase/jdk9certconfig-3761018.html , Osx 10.10 and above are supported version for JDK9. I am not sure about JDK10.
03-10-2017
Setting back to P3, given the limited scope of the problem (unsupported OS versions + uncommon configuration).
29-09-2017
As it is a regression and crash on "java --version" itself, increasing the priority to P2.
21-09-2017
It is a regression and started from JDK 10 build 15 on wards. Looks like regression introduced by task JDK-8160199
21-09-2017
Need to check if the devkit for macos was updated in JDK 10. Also need to check if 10.10.5 is still supported.
21-09-2017
The crash is coming from libjava: C [libsystem_platform.dylib+0x1380] _platform_memmove$VARIANT$Nehalem+0x40 C [libjava.dylib+0xcf44] convertToPOSIXLocale+0x8f C [libjava.dylib+0xce84] getMacOSXLocale+0x185 C [libjava.dylib+0xcf7e] setupMacOSXLocale+0xd C [libjava.dylib+0xdcaf] ParseLocale+0x2e C [libjava.dylib+0xdb01] GetJavaProperties+0x1aa C [libjava.dylib+0x6f27] Java_java_lang_System_initProperties+0x31 Moving to core-libs->java.lang
21-09-2017