JDK-8139390 : Very long classname in jimage causes SIGSEGV
  • Type: Bug
  • Component: core-libs
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-10-12
  • Updated: 2017-05-24
  • Resolved: 2015-10-30
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 9
9 b92Fixed
Related Reports
Relates :  
JDK-8087181 - Move native jimage code to its own library (maybe libjimage)
Relates :  
JDK-8136497 - vm/mlvm/anonloader/func/invalidSuperclass fails on windows
Description
#  SIGSEGV (0xb) at pc=0xf634b13e, pid=28154, tid=28165
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20151009192118.iggy.8136725-b00)
# Java VM: Java HotSpot(TM) Server VM (1.9.0-internal-fastdebug-20151009192118.iggy.8136725-b00, compiled modeg1 gclinux-x86, (null), (null))
# Problematic frame:
# V  [libjvm.so+0x68513e]  VectorNode::ideal_reg() const+0x1e
#
Comments
It's verified by running test jdk/internal/jimage/JImageReadTest.java on JDK 9 build 170.
24-05-2017
Review thread on jigsaw-dev: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-October/005015.html
28-10-2015
The invalidSuperclass test creates a classfile with a parent class that is 9999 characters long. In a few places, the native code allocates working buffers of 4096 characters.
23-10-2015
Right, the code in classLoader.cpp is ok; the problem is elsewhere. The code is in jdk/src/java.base/share/native/libjimage/jimage.cpp: 108.
23-10-2015
Roger I will be unavailable for several weeks. You wrote the core of this code, will you take a look?
14-10-2015
Hi, the same test fails on Windows since the fix for JDK-8087181 has been pushed. That problem is tracked by JDK-8136497. In the current failure, the call into compiler-related code (VectorNode::ideal_reg()) from ClassPathImageEntry::open_stream seems to be random: V [libjvm.so+0x68513e] VectorNode::ideal_reg() const+0x1e;; VectorNode::ideal_reg() const+0x1e V [libjvm.so+0x66cefb] ClassPathImageEntry::open_stream(char const*, Thread*)+0x17b;; ClassPathImageEntry::open_stream(char const*, Thread*)+0x17b V [libjvm.so+0x674f93] ClassLoader::load_classfile(Symbol*, Thread*)+0x243;; ClassLoader::load_classfile(Symbol*, Thread*)+0x243 V [libjvm.so+0x102b315] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x695;; SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x695 V [libjvm.so+0x1028d13] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0xad3;; SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0xad3 V [libjvm.so+0x10293bb] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x11b;; SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x11b V [libjvm.so+0x1029648] SystemDictionary::resolve_or_null(Symbol*, Thread*)+0x28;; SystemDictionary::resolve_or_null(Symbol*, Thread*)+0x28 V [libjvm.so+0xb18fd7] JVM_FindClassFromBootLoader+0x277;; JVM_FindClassFromBootLoader+0x277 ... The likely cause of the problem is the corruption of the function pointer at any of the following locations: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/262b86c271b0#l10.140 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/262b86c271b0#l10.169 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/262b86c271b0#l10.183 (as Dean already mentioned). Based on the currently available evidence, this problem is not caused by the JIT compiler. Therefore, I'm changing the component of the current issue to core-libs and assign it to Jim Laskey (Jim is the author of JDK-8087181 that was filed against the component core-libs). I did the same for JDK-8136497. Furthermore, the fix for JDK-8136497 might fix the current issue as well. Thank you and best regards, Zoltan
14-10-2015
It looks like ClassPathImageEntry::open_stream is calling into random functions. It could be that the function pointers it uses, are getting corrupted: JImagePackageToModule, JImageFindResource, JImageGetResource.
13-10-2015