JDK-8275843 : Random crashes while the UI code is executed
  • Type: Bug
  • Component: client-libs
  • Affected Version: 11,17,18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2021-10-23
  • Updated: 2023-11-08
  • Resolved: 2021-12-14
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 17 JDK 19
17.0.7Fixed 19 b02Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
While executing some UI applications on the various Linux environments including virtual environment, docker, or just on the physical PC the java sometimes crashed in random places.

The stack information in the core file is always broken, sometimes hs_file contains the report below, but I think this is not a root cause and just a result of already broken memory.

#0  0x0000ffffb8983470 in raise () from /lib64/libc.so.6
#1  0x0000ffffb8984cb4 in abort () from /lib64/libc.so.6
#2  0x0000ffffb89be860 in __libc_message () from /lib64/libc.so.6
#3  0x0000ffffb89c4c84 in malloc_printerr () from /lib64/libc.so.6
#4  0x0000ffffb89c69a0 in _int_free () from /lib64/libc.so.6
#5  0x0000ffffb6f3e0bc in Chunk::operator delete (p=0xffffb070d300) at /jdk/src/hotspot/share/memory/arena.cpp:199
#6  Chunk::chop (this=<optimized out>) at /jdk/src/hotspot/share/memory/arena.cpp:213
#7  0x0000ffffb6f3e178 in Chunk::next_chop (this=0xffffb0029170) at /jdk/src/hotspot/share/memory/arena.cpp:219
#8  0x0000ffffb70fe88c in ResourceArea::rollback_to (state=..., this=0xffffb00273a0) at /jdk/src/hotspot/share/memory/resourceArea.hpp:119
#9  ResourceMarkImpl::reset_to_mark (this=0xffffb6875880) at /jdk/src/hotspot/share/memory/resourceArea.hpp:163
#10 ResourceMarkImpl::~ResourceMarkImpl (this=0xffffb6875880, __in_chrg=<optimized out>) at /jdk/src/hotspot/share/memory/resourceArea.hpp:158
#11 0x0000ffffb7c16da8 in ResourceMark::~ResourceMark (this=0x0, __in_chrg=<optimized out>) at /jdk/src/hotspot/share/memory/resourceArea.hpp:204
#12 nmethod::check_all_dependencies (changes=...) at /jdk/src/hotspot/share/code/nmethod.cpp:2231
#13 0x0000ffffb72649c8 in CodeCache::mark_for_deoptimization (changes=...) at /jdk/src/hotspot/share/code/codeCache.cpp:1020
#14 0x0000ffffb7264bb8 in CodeCache::flush_dependents_on (dependee=dependee@entry=0x80109eed0) at /jdk/src/hotspot/share/code/codeCache.cpp:1189
#15 0x0000ffffb801afd0 in SystemDictionary::add_to_hierarchy (k=k@entry=0x80109eed0) at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:1583
#16 0x0000ffffb8020c9c in SystemDictionary::define_instance_class (k=k@entry=0x80109eed0, class_loader=..., __the_thread__=__the_thread__@entry=0xffffb0028b40) at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:1440
#17 0x0000ffffb8020fd4 in SystemDictionary::find_or_define_helper (class_name=class_name@entry=0xffff991eee80, class_loader=..., k=k@entry=0x80109eed0, __the_thread__=__the_thread__@entry=0xffffb0028b40)
    at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:1524
#18 0x0000ffffb802117c in SystemDictionary::find_or_define_instance_class (class_name=class_name@entry=0xffff991eee80, class_loader=..., class_loader@entry=..., k=k@entry=0x80109eed0, __the_thread__=__the_thread__@entry=0xffffb0028b40)
    at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:1546
#19 0x0000ffffb8022fac in SystemDictionary::load_instance_class_impl (class_name=class_name@entry=0xffff991eee80, class_loader=..., __the_thread__=__the_thread__@entry=0xffffb0028b40)
    at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:1294
#20 0x0000ffffb8021510 in SystemDictionary::load_instance_class (name_hash=name_hash@entry=266064372, name=name@entry=0xffff991eee80, class_loader=..., __the_thread__=__the_thread__@entry=0xffffb0028b40)
    at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:1353
#21 0x0000ffffb8021c1c in SystemDictionary::resolve_instance_class_or_null (name=name@entry=0xffff991eee80, class_loader=..., protection_domain=..., __the_thread__=__the_thread__@entry=0xffffb0028b40)
    at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:722
#22 0x0000ffffb8021ebc in SystemDictionary::resolve_instance_class_or_null_helper (class_name=class_name@entry=0xffff991eee80, class_loader=..., protection_domain=..., __the_thread__=__the_thread__@entry=0xffffb0028b40)
    at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:293
#23 0x0000ffffb80234a4 in SystemDictionary::resolve_or_null (__the_thread__=0xffffb0028b40, protection_domain=..., class_loader=..., class_name=0xffff991eee80) at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:276
#24 SystemDictionary::resolve_or_fail (class_name=class_name@entry=0xffff991eee80, class_loader=..., protection_domain=..., throw_error=throw_error@entry=true, __the_thread__=__the_thread__@entry=0xffffb0028b40)
    at /jdk/src/hotspot/share/classfile/systemDictionary.cpp:262
#25 0x0000ffffb72f59f4 in ConstantPool::klass_at_impl (this_cp=..., which=which@entry=542, __the_thread__=__the_thread__@entry=0xffffb0028b40) at /jdk/src/hotspot/share/oops/constantPool.cpp:513
#26 0x0000ffffb76bf7e4 in ConstantPool::klass_at (__the_thread__=0xffffb0028b40, which=542, this=0xffff9882e550) at /jdk/src/hotspot/share/oops/constantPool.hpp:401
#27 InterpreterRuntime::_new (current=0xffffb0028b40, pool=0xffff9882e550, index=542) at /jdk/src/hotspot/share/interpreter/interpreterRuntime.cpp:218
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2122 Date: 2023-09-05 17:20:19 +0000
08-11-2023

Fix request (17u) Clean backport. Fix for a regression introduced in jdk13 b30. Verified by the "steps to reproduce" above under X11 when 16 bits depth is used. The jdk_desktop tests are green. Review 17u-dev: https://github.com/openjdk/jdk17u-dev/pull/993
31-12-2022

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/993 Date: 2022-12-29 05:55:46 +0000
31-12-2022

Changeset: a9c1acbb Author: Sergey Bylokhov <serb@openjdk.org> Date: 2021-12-14 18:03:00 +0000 URL: https://git.openjdk.java.net/jdk/commit/a9c1acbb8aec46e4a488b7c77bb6318af87747f6
14-12-2021

Let's review it for 19.
10-12-2021

This is another wagon in this train: JDK-8176795->JDK-8204931->JDK-8214579->JDK-8227392->Current issue. I think that the current issue is the same as was reported by the JDK-8214579, which was rolled back by the JDK-8227392. Looks like nobody realized that the wrong rendering was caused by the broken memory access and the last fix(JDK-8227392) solved one JCK issue in one particular case but reintroduce the crashes. The change caused mismatch is JDK-8204931.
26-10-2021