-
Bug
-
Resolution: Fixed
-
P4
-
11, 17, 18, 19
-
b14
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8284217 | 18.0.2 | Zhengyu Gu | P4 | Resolved | Fixed | b02 |
| JDK-8284218 | 17.0.4 | Zhengyu Gu | P4 | Resolved | Fixed | b01 |
| JDK-8284235 | 11.0.16 | Zhengyu Gu | P4 | Resolved | Fixed | b01 |
The native method: Java_sun_util_locale_provider_HostLocaleProviderAdapterImpl_getNumberPattern(...) {
...
langtag = (*env)->GetStringChars(env, jlangtag, JNI_FALSE);
CHECK_NULL_RETURN(langtag, NULL);
pattern = getNumberPattern(langtag, numberStyle);
CHECK_NULL_RETURN(pattern, NULL);
(*env)->ReleaseStringChars(env, jlangtag, langtag);
...
}
If getNumberPattern() call returns NULL, langtag is not released.
Also, the call GetStringChars(env, jlangtag, JNI_FALSE) looks weird, as the last parameter should be a pointer to jboolean, not a jboolean. It works due to JNI_FALSE == 0 (or NULL).
- backported by
-
JDK-8284217 Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows
-
- Resolved
-
-
JDK-8284218 Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows
-
- Resolved
-
-
JDK-8284235 Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows
-
- Resolved
-
- links to
-
Commit
openjdk/jdk11u-dev/2f1bee61
-
Commit
openjdk/jdk17u-dev/e8db3465
-
Commit
openjdk/jdk18u/8f4dbe59
-
Commit
openjdk/jdk/2cddf3f5
-
Review
openjdk/jdk11u-dev/965
-
Review
openjdk/jdk17u-dev/317
-
Review
openjdk/jdk18u/86
-
Review
openjdk/jdk/7777