Segmentation Fault occurs when ClassLoader and Metaspace is released in JDK 8
Osamu Sakamoto
sakamoto.osamu at nttcom.co.jp
Fri Oct 25 08:53:35 UTC 2019
Hi Yasumasa,
> I guess this is a bug in combination of Metaspace and CMS.
> However current jdk/jdk has different implementation, so it might not
be occur in modern JDK.
> I want to hear the comments from others.
Thank you for your comment.
I want to hear from others, too
> AFAICS you cannot find head of _unloading at this point.
> However you can traverse CLD list with purge_me->_next .
Thank you for telling me how to traverse CLD list.
I could start to traverse the CLD list, but this list is too long to
traverse manually.
I recursively chekced _next -> _next -> next ... about 500 times with
GDB print command, but NULL termination or address loop isn't found yet.
I'll try to find a good way to traverse the CLD list to the end.
> BTW, CLD has OOP for class loader in ClassLoaderData::_class_loader .
> If you check it on (CL)HSDB, you might get any hints from it.
> For example, use system class loader instead of custom class loader
from framework.
I checked CLD oop, but I don't understand what type of ClassLoader is.
The result is below.
It looks like that this ClassLoaderData::_class_loader oop indicates
character array.
Is it normal?
If so, what is this class loader?(Bootstrap ClassLoader?)
---------------------------------------------------
(gdb) p ClassLoaderData::_class_loader
$21 = (oop) 0xa3afc1f0
hsdb> inspect 0xa3afc1f0
instance of [C @ 0x00000000a3afc1f0 @ 0x00000000a3afc1f0 (size = 72)
_mark: 1
_metadata._compressed_klass: TypeArrayKlass for [C
0: 'c'
1: 'o'
2: 'l'
3: 'u'
4: 'm'
5: 'n'
6: '1'
7: '5'
8: '6'
9: '5'
10: '7'
11: '5'
12: '5'
13: '9'
14: '8'
15: '6'
16: '3'
17: '3'
18: '1'
19: '_'
20: '8'
21: '0'
22: '0'
23: '3'
---------------------------------------------------
Thanks,
Osamu
On 10/24/19 09:49, Yasumasa Suenaga wrote:
> Hi Osamu,
>
> I guess this is a bug in combination of Metaspace and CMS.
> However current jdk/jdk has different implementation, so it might not
> be occur in modern JDK.
> I want to hear the comments from others.
>
> My comments is below:
>
> On 2019/10/23 18:57, Osamu Sakamoto wrote:
>> Hi Yasumasa,
>>
>> Thank you for answering.
>>
>> > What JVM options did you pass?
>> The following is the JVM options I passed.
>> -----------------------------------------------------------------
>> -Xmx2048m
>> -Xms2048m
>> -XX:NewSize=412m
>> -XX:MaxNewSize=412m
>> -XX:SurvivorRatio=8
>> -XX:MaxTenuringThreshold=15
>> -XX:+UseConcMarkSweepGC
>> -XX:+UseCMSInitiatingOccupancyOnly
>> -XX:CMSInitiatingOccupancyFraction=80
>> -XX:+CMSClassUnloadingEnabled
>> -XX:CompressedClassSpaceSize=64m
>> -XX:+PrintGCDetails
>> -XX:+PrintGCDateStamps
>> -XX:+UseGCLogFileRotation
>> -XX:GCLogFileSize=0
>> -Xloggc:/var/log/tomcatm0/gc-%p.log
>> -XX:+HeapDumpOnOutOfMemoryError
>> -XX:+AlwaysLockClassLoader
>> -----------------------------------------------------------------
>>
>>
>> > I guess you used CMS because this problem seems to occur on CMS
>> only [1] [2].
>> Yes, I used CMS.
>>
>> > So it might be work around not to use CMS.
>> Thank you for telling me work around.
>> But it is difficult to change the GC method, so we would like to
>> solve this issue with CMS GC if possible.
>>
>>
>> > I'm not sure root cause of this issue, but it seems to break
>> ClassLoaderDataGraph::_unloading.
>> > (like double free (delete) of CLD)
>> I checked whether the ClassLoaderDataGraph::_unloading is broken or
>> not, but I didn't know because of the value has been cleaered by NULL
>> or optimized out.
>>
>> Referring ClassLoaderDataGraph[1].cpp, it looks like that _unloading
>> value is saved to ClassLoaderDataGraph::_saved_unloading.
>> But _saved_unloading had been cleared by NULL, too.
>>
>> Is there any other way to check it?
>>
>> [1]http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/eed8e846c982/src/share/vm/classfile/classLoaderData.cpp#l753
>>
>>
>> -----------------------------------------------------------------
>> (gdb) f 10
>> #10 0x00007f60808c0f0f in ClassLoaderDataGraph::purge () at
>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/classfile/classLoaderData.cpp:818
>> 818 delete purge_me;
>> (gdb) list ClassLoaderDataGraph::purge
>> 810 void ClassLoaderDataGraph::purge() {
>> 811 assert(SafepointSynchronize::is_at_safepoint(), "must be at
>> safepoint!");
>> 812 ClassLoaderData* list = _unloading;
>> 813 _unloading = NULL;
>> 814 ClassLoaderData* next = list;
>> 815 while (next != NULL) {
>> 816 ClassLoaderData* purge_me = next;
>> 817 next = purge_me->next();
>> 818 delete purge_me;
>> 819 }
>> 820 Metaspace::purge();
>> 821 }
>> (gdb) p _unloading
>> $29 = (ClassLoaderData *) 0x0
>> (gdb) p list
>> $30 = <optimized out>
>> (gdb) p next
>> $31 = <optimized out>
>> (gdb) p ClassLoaderDataGraph::_saved_unloading
>> $32 = (ClassLoaderData *) 0x0
>> -----------------------------------------------------------------
>
> AFAICS you cannot find head of _unloading at this point.
> However you can traverse CLD list with purge_me->_next .
>
>
> BTW, CLD has OOP for class loader in ClassLoaderData::_class_loader .
> If you check it on (CL)HSDB, you might get any hints from it.
> For example, use system class loader instead of custom class loader
> from framework.
>
>
> Thanks,
>
> Yasumasa
>
>
>> Thanks,
>> Osamu
>>
>> On 10/21/19 22:29, Yasumasa Suenaga wrote:
>>> Hi Osamu,
>>>
>>> What JVM options did you pass?
>>>
>>> I guess you used CMS because this problem seems to occur on CMS only
>>> [1] [2].
>>> So it might be work around not to use CMS.
>>>
>>> I'm not sure root cause of this issue, but it seems to break
>>> ClassLoaderDataGraph::_unloading.
>>> (like double free (delete) of CLD)
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> [1]
>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/eed8e846c982/src/share/vm/classfile/classLoaderData.hpp#l100
>>> [2]
>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/eed8e846c982/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp#l6384
>>>
>>>
>>> On 2019/10/21 17:50, Osamu Sakamoto wrote:
>>>> Hi all,
>>>>
>>>> I have a problem about Segmentation Fault(SEGV) in GC and I can't
>>>> make the cause clear.
>>>> Could you help me solve the problem?
>>>>
>>>> Our System uses OpenJDK 1.8.0.181, and crashed by SEGV when purging
>>>> ClassLoader at safepoint.
>>>> This problem can't be reproduced, but this has happened 4 times in
>>>> a few months.
>>>>
>>>> The following is the summary of my investigation.
>>>>
>>>> =============================================================================
>>>>
>>>>
>>>> First I checked hs_err, and that shows that the SEGV occurred.
>>>> VM_Operation is GenCollectForAllocation at safepoint.
>>>>
>>>> -----------------------------------------------------------------------------
>>>>
>>>> #
>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>> #
>>>> # SIGSEGV (0xb) at pc=0x00007f6080c97f88, pid=23931,
>>>> tid=0x00007f607c3ed700
>>>> #
>>>> # JRE version: OpenJDK Runtime Environment (8.0_181-b13) (build
>>>> 1.8.0_181-b13)
>>>> # Java VM: OpenJDK 64-Bit Server VM (25.181-b13 mixed mode
>>>> linux-amd64 compressed oops)
>>>> # Problematic frame:
>>>> # V [libjvm.so+0x84bf88]
>>>> #
>>>> # Core dump written. Default location: /opt/tomcate0/core or
>>>> core.23931
>>>> #
>>>> # If you would like to submit a bug report, please visit:
>>>> # http://bugreport.java.com/bugreport/crash.jsp
>>>> #
>>>>
>>>> --------------- T H R E A D ---------------
>>>>
>>>> Current thread (0x00007f6078c00000): VMThread [stack:
>>>> 0x00007f607c2ed000,0x00007f607c3ee000] [id=23939]
>>>>
>>>> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
>>>> 0x0000000000000018
>>>>
>>>> Registers:
>>>> RAX=0x0000000000000010, RBX=0x00007f5ff800ad30,
>>>> RCX=0x0000000000000010, RDX=0x0000000000000000
>>>> RSP=0x00007f607c3ecb50, RBP=0x00007f607c3ecb80,
>>>> RSI=0x0000000000000002, RDI=0x0000000001cfe570
>>>> R8 =0x00007f5ff80ae320, R9 =0x00007f5ff8052480,
>>>> R10=0x0000000000000000, R11=0x0000000000000400
>>>> R12=0x0000000001cfe570, R13=0x00007f6081419470,
>>>> R14=0x0000000000000002, R15=0x00007f6081418640
>>>> RIP=0x00007f6080c97f88, EFLAGS=0x0000000000010202,
>>>> CSGSFS=0x0000000000000033, ERR=0x0000000000000004
>>>> TRAPNO=0x000000000000000e
>>>>
>>>> Top of Stack: (sp=0x00007f607c3ecb50)
>>>> 0x00007f607c3ecb50: 00007f607c3ecba0 00007f5ff800ad30
>>>> 0x00007f607c3ecb60: 00007f5ff800ad00 0000000000000000
>>>> 0x00007f607c3ecb70: 0000000000000000 0000000000000001
>>>> 0x00007f607c3ecb80: 00007f607c3ecba0 00007f6080c995fa
>>>> 0x00007f607c3ecb90: 00007f5ff800ad00 00007f5ff800ac20
>>>> 0x00007f607c3ecba0: 00007f607c3ecbc0 00007f60808bff5e
>>>> 0x00007f607c3ecbb0: 00007f5ff800ac20 00007f5ff8052870
>>>> 0x00007f607c3ecbc0: 00007f607c3ecbe0 00007f60808c0f0f
>>>> 0x00007f607c3ecbd0: 00007f607c3ecbf0 00007f608140f308
>>>> 0x00007f607c3ecbe0: 00007f607c3ecc30 00007f6080daa0b7
>>>> 0x00007f607c3ecbf0: 00007f6069000100 0000000000000000
>>>> 0x00007f607c3ecc00: 00007f607c3ecc20 00007f6080ed0800
>>>> 0x00007f607c3ecc10: 00000000000000f9 88e95c3ba257ab00
>>>> 0x00007f607c3ecc20: 431bde82d7b634db 00007f607800aa00
>>>> 0x00007f607c3ecc30: 00007f607c3eccc0 00007f6080daa9d5
>>>> 0x00007f607c3ecc40: 0000000000000000 00007f607803bf20
>>>> 0x00007f607c3ecc50: 00007f607803be20 00000000000003e8
>>>> 0x00007f607c3ecc60: 0000000000000001 00007f6078c00000
>>>> 0x00007f607c3ecc70: 00007f607c3eccc0 0000000000000000
>>>> 0x00007f607c3ecc80: 00000004000000f9 00007f60813e2b99
>>>> 0x00007f607c3ecc90: 00007f607803bfa0 00007f6078c00000
>>>> 0x00007f607c3ecca0: 0000000000000000 0000000000000000
>>>> 0x00007f607c3eccb0: 00007f6081418bd0 00007f607803bf20
>>>> 0x00007f607c3eccc0: 00007f607c3ece60 00007f6080f2048a
>>>> 0x00007f607c3eccd0: 00007f607c3ecd20 00007f607c3ecce0
>>>> 0x00007f607c3ecce0: 00007f6078c00000 00007f6078c00980
>>>> 0x00007f607c3eccf0: 00007f6078c009c0 00007f6078c009d0
>>>> 0x00007f607c3ecd00: 00007f6078c00aa8 00000000000000d8
>>>> 0x00007f607c3ecd10: 00007f6078c00be0 0000000000000000
>>>> 0x00007f607c3ecd20: 00007f607c3ecd28 6e69747563657845
>>>> 0x00007f607c3ecd30: 65706f204d562067 203a6e6f69746172
>>>> 0x00007f607c3ecd40: 656c6c6f436e6547 6c6c41726f467463
>>>>
>>>> Instructions: (pc=0x00007f6080c97f88)
>>>> 0x00007f6080c97f68: b6 12 80 fa 00 74 01 f0 48 0f c1 01 31 c9 31 f6
>>>> 0x00007f6080c97f78: 48 8b 44 0b 10 31 d2 48 85 c0 74 11 0f 1f 40 00
>>>> 0x00007f6080c97f88: 48 8b 40 08 48 83 c2 01 48 85 c0 75 f3 48 83 c1
>>>> 0x00007f6080c97f98: 08 48 01 d6 48 83 f9 20 75 d6 8b 7b 08 48 8b 05
>>>>
>>>> Register to memory mapping:
>>>>
>>>> RAX=0x0000000000000010 is an unknown value
>>>> RBX=0x00007f5ff800ad30 is an unknown value
>>>> RCX=0x0000000000000010 is an unknown value
>>>> RDX=0x0000000000000000 is an unknown value
>>>> RSP=0x00007f607c3ecb50 is an unknown value
>>>> RBP=0x00007f607c3ecb80 is an unknown value
>>>> RSI=0x0000000000000002 is an unknown value
>>>> RDI=0x0000000001cfe570 is an unknown value
>>>> R8 =0x00007f5ff80ae320 is an unknown value
>>>> R9 =0x00007f5ff8052480 is an unknown value
>>>> R10=0x0000000000000000 is an unknown value
>>>> R11=0x0000000000000400 is an unknown value
>>>> R12=0x0000000001cfe570 is an unknown value
>>>> R13=0x00007f6081419470: <offset 0xfcd470> in
>>>> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/jre/lib/amd64/server/libjvm.so
>>>> at 0x00007f608044c000
>>>> R14=0x0000000000000002 is an unknown value
>>>> R15=0x00007f6081418640: <offset 0xfcc640> in
>>>> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/jre/lib/amd64/server/libjvm.so
>>>> at 0x00007f608044c000
>>>>
>>>>
>>>> Stack: [0x00007f607c2ed000,0x00007f607c3ee000],
>>>> sp=0x00007f607c3ecb50, free space=1022k
>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>> C=native code)
>>>> V [libjvm.so+0x84bf88]
>>>> V [libjvm.so+0x84d5fa]
>>>> V [libjvm.so+0x473f5e]
>>>> V [libjvm.so+0x474f0f]
>>>> V [libjvm.so+0x95e0b7]
>>>> V [libjvm.so+0x95e9d5]
>>>> V [libjvm.so+0xad448a]
>>>> V [libjvm.so+0xad48f1]
>>>> V [libjvm.so+0x8beb82]
>>>>
>>>> VM_Operation (0x00007f5fd69e6120): GenCollectForAllocation, mode:
>>>> safepoint, requested by thread 0x00007f6079013800
>>>>
>>>> ...
>>>> -----------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> Next, I used GDB to check the backtrace of the SEGV thread from the
>>>> coredump.
>>>> The following is the backtrace.
>>>> The SEGV occurred when ClassLoader is purged and Metaspace is
>>>> destructed.
>>>> And frame #7 shows that a signal(SEGV) handler is called after
>>>> SpaceManager::~SpaceManager() is executed.
>>>>
>>>> -----------------------------------------------------------------------------
>>>>
>>>> (gdb) bt
>>>> #0 0x00007f608146f1f7 in __GI_raise (sig=sig at entry=6) at
>>>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>>>> #1 0x00007f60814708e8 in __GI_abort () at abort.c:90
>>>> #2 0x00007f6080d0bc39 in os::abort (dump_core=<optimized out>) at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1519
>>>> #3 0x00007f6080f1b816 in VMError::report_and_die
>>>> (this=this at entry=0x7f607c3ebd10) at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1060
>>>> #4 0x00007f6080d15927 in JVM_handle_linux_signal (sig=11,
>>>> info=0x7f607c3ebfb0, ucVoid=0x7f607c3ebe80,
>>>> abort_if_unrecognized=<optimized out>)
>>>> at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:541
>>>> #5 0x00007f6080d09038 in signalHandler (sig=11,
>>>> info=0x7f607c3ebfb0, uc=0x7f607c3ebe80) at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4446
>>>> #6 <signal handler called>
>>>> #7 SpaceManager::~SpaceManager (this=0x7f5ff800ad30,
>>>> __in_chrg=<optimized out>) at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/memory/metaspace.cpp:2028
>>>> #8 0x00007f6080c995fa in Metaspace::~Metaspace
>>>> (this=0x7f5ff800ad00, __in_chrg=<optimized out>)
>>>> at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/memory/metaspace.cpp:2971
>>>> #9 0x00007f60808bff5e in ClassLoaderData::~ClassLoaderData
>>>> (this=0x7f5ff800ac20, __in_chrg=<optimized out>)
>>>> at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/classfile/classLoaderData.cpp:383
>>>> #10 0x00007f60808c0f0f in ClassLoaderDataGraph::purge () at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/classfile/classLoaderData.cpp:818
>>>>
>>>> #11 0x00007f6080daa0b7 in ClassLoaderDataGraph::purge_if_needed ()
>>>> at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/classfile/classLoaderData.hpp:104
>>>> #12 SafepointSynchronize::do_cleanup_tasks () at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/runtime/safepoint.cpp:551
>>>> #13 0x00007f6080daa9d5 in SafepointSynchronize::begin () at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/runtime/safepoint.cpp:402
>>>>
>>>> #14 0x00007f6080f2048a in VMThread::loop
>>>> (this=this at entry=0x7f6078c00000) at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/runtime/vmThread.cpp:501
>>>> #15 0x00007f6080f208f1 in VMThread::run (this=0x7f6078c00000) at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/runtime/vmThread.cpp:276
>>>> #16 0x00007f6080d0ab82 in java_start (thread=0x7f6078c00000) at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:796
>>>> #17 0x00007f6081e2de25 in start_thread (arg=0x7f607c3ed700) at
>>>> pthread_create.c:308
>>>> #18 0x00007f608153234d in clone () at
>>>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
>>>> -----------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> In Frame #7, Line 2028 (chunk = chunk->next()) is the crash point.
>>>> The variable "chunk" is defined at Line 2025 (Metachunk* chunk =
>>>> chunks_in_use(i);).
>>>> "chunks_in_use(i)" is defined at Line 648 (Metachunk*
>>>> chunks_in_use(ChunkIndex index) const { return
>>>> _chunks_in_use[index]; }).
>>>> So I checked values of "_chunks_in_use", and understood that
>>>> "_chunks_in_use[2]" has Illegal Address "0x10".
>>>> Therefore, I think that the SEGV occurred because of referencing
>>>> Illegal Address "0x10" at "chunk = chunk->next()".
>>>>
>>>> -----------------------------------------------------------------------------
>>>>
>>>> (gdb) f 7
>>>> #7 SpaceManager::~SpaceManager (this=0x7f5ff800ad30,
>>>> __in_chrg=<optimized out>) at
>>>> /usr/src/debug/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/openjdk/hotspot/src/share/vm/memory/metaspace.cpp:2028
>>>> 2028 chunk = chunk->next();
>>>> (gdb) list
>>>> 2023 size_t SpaceManager::sum_count_in_chunks_in_use(ChunkIndex
>>>> i) {
>>>> 2024 size_t count = 0;
>>>> 2025 Metachunk* chunk = chunks_in_use(i);
>>>> 2026 while (chunk != NULL) {
>>>> 2027 count++;
>>>> 2028 chunk = chunk->next();
>>>> 2029 }
>>>> 2030 return count;
>>>> 2031 }
>>>> 2032
>>>> (gdb) list SpaceManager::chunks_in_use
>>>> 647 // Accessors
>>>> 648 Metachunk* chunks_in_use(ChunkIndex index) const { return
>>>> _chunks_in_use[index]; }
>>>> ...
>>>> (gdb) p _chunks_in_use
>>>> $11 = {0x7f5fcd41c400, 0x7f5fcd41a000, 0x10, 0x0}
>>>> -----------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> The following is disassemble code of "SpaceManager::~SpaceManager()".
>>>> %rax has 0x10 at "0x00007f6080c97f88 <+200>", but I don't
>>>> understand why this "0x10" is inserted to %rax.
>>>>
>>>> -----------------------------------------------------------------------------
>>>>
>>>> (gdb) disas
>>>> Dump of assembler code for function SpaceManager::~SpaceManager():
>>>> 0x00007f6080c97ec0 <+0>: push %rbp
>>>> 0x00007f6080c97ec1 <+1>: mov %rsp,%rbp
>>>> 0x00007f6080c97ec4 <+4>: push %r15
>>>> 0x00007f6080c97ec6 <+6>: push %r14
>>>> 0x00007f6080c97ec8 <+8>: push %r13
>>>> 0x00007f6080c97eca <+10>: push %r12
>>>> 0x00007f6080c97ecc <+12>: push %rbx
>>>> 0x00007f6080c97ecd <+13>: mov %rdi,%rbx
>>>> 0x00007f6080c97ed0 <+16>: sub $0x8,%rsp
>>>> 0x00007f6080c97ed4 <+20>: mov 0x780785(%rip),%r12 #
>>>> 0x7f6081418660 <_ZN12SpaceManager12_expand_lockE>
>>>> 0x00007f6080c97edb <+27>: test %r12,%r12
>>>> 0x00007f6080c97ede <+30>: je 0x7f6080c97ee8
>>>> <SpaceManager::~SpaceManager()+40>
>>>> 0x00007f6080c97ee0 <+32>: mov %r12,%rdi
>>>> 0x00007f6080c97ee3 <+35>: callq 0x7f6080cce2f0
>>>> <Monitor::lock_without_safepoint_check()>
>>>> 0x00007f6080c97ee8 <+40>: movslq 0x8(%rbx),%rcx
>>>> 0x00007f6080c97eec <+44>: lea 0x78075d(%rip),%rdx #
>>>> 0x7f6081418650 <_ZN12MetaspaceAux15_capacity_wordsE>
>>>> 0x00007f6080c97ef3 <+51>: lea 0x781576(%rip),%r13 #
>>>> 0x7f6081419470 <_ZN2os16_processor_countE>
>>>> 0x00007f6080c97efa <+58>: lea 0x78073f(%rip),%r15 #
>>>> 0x7f6081418640 <_ZN12MetaspaceAux11_used_wordsE>
>>>> 0x00007f6080c97f01 <+65>: mov (%rdx,%rcx,8),%rax
>>>> 0x00007f6080c97f05 <+69>: sub 0x40(%rbx),%rax
>>>> 0x00007f6080c97f09 <+73>: mov %rax,(%rdx,%rcx,8)
>>>> 0x00007f6080c97f0d <+77>: mov 0x38(%rbx),%rax
>>>> 0x00007f6080c97f11 <+81>: movslq 0x8(%rbx),%rdx
>>>> 0x00007f6080c97f15 <+85>: neg %rax
>>>> 0x00007f6080c97f18 <+88>: cmpl $0x1,0x0(%r13)
>>>> 0x00007f6080c97f1d <+93>: lea (%r15,%rdx,8),%rcx
>>>> 0x00007f6080c97f21 <+97>: mov $0x1,%edx
>>>> 0x00007f6080c97f26 <+102>: jne 0x7f6080c97f32
>>>> <SpaceManager::~SpaceManager()+114>
>>>> 0x00007f6080c97f28 <+104>: lea 0x74acb4(%rip),%rdx #
>>>> 0x7f60813e2be3 <AssumeMP>
>>>> 0x00007f6080c97f2f <+111>: movzbl (%rdx),%edx
>>>> 0x00007f6080c97f32 <+114>: cmp $0x0,%dl
>>>> 0x00007f6080c97f35 <+117>: je 0x7f6080c97f38
>>>> <SpaceManager::~SpaceManager()+120>
>>>> 0x00007f6080c97f37 <+119>: lock xadd %rax,(%rcx)
>>>> 0x00007f6080c97f3c <+124>: mov 0x48(%rbx),%r14
>>>> 0x00007f6080c97f40 <+128>: callq 0x7f6080c951a0
>>>> <Metachunk::overhead()>
>>>> 0x00007f6080c97f45 <+133>: movslq 0x8(%rbx),%rdx
>>>> 0x00007f6080c97f49 <+137>: imul %r14,%rax
>>>> 0x00007f6080c97f4d <+141>: lea (%r15,%rdx,8),%rcx
>>>> 0x00007f6080c97f51 <+145>: mov $0x1,%edx
>>>> 0x00007f6080c97f56 <+150>: neg %rax
>>>> 0x00007f6080c97f59 <+153>: cmpl $0x1,0x0(%r13)
>>>> 0x00007f6080c97f5e <+158>: jne 0x7f6080c97f6a
>>>> <SpaceManager::~SpaceManager()+170>
>>>> 0x00007f6080c97f60 <+160>: lea 0x74ac7c(%rip),%rdx #
>>>> 0x7f60813e2be3 <AssumeMP>
>>>> 0x00007f6080c97f67 <+167>: movzbl (%rdx),%edx
>>>> 0x00007f6080c97f6a <+170>: cmp $0x0,%dl
>>>> 0x00007f6080c97f6d <+173>: je 0x7f6080c97f70
>>>> <SpaceManager::~SpaceManager()+176>
>>>> 0x00007f6080c97f6f <+175>: lock xadd %rax,(%rcx)
>>>> 0x00007f6080c97f74 <+180>: xor %ecx,%ecx
>>>> 0x00007f6080c97f76 <+182>: xor %esi,%esi
>>>> 0x00007f6080c97f78 <+184>: mov 0x10(%rbx,%rcx,1),%rax
>>>> 0x00007f6080c97f7d <+189>: xor %edx,%edx
>>>> 0x00007f6080c97f7f <+191>: test %rax,%rax
>>>> 0x00007f6080c97f82 <+194>: je 0x7f6080c97f95
>>>> <SpaceManager::~SpaceManager()+213>
>>>> 0x00007f6080c97f84 <+196>: nopl 0x0(%rax)
>>>> => 0x00007f6080c97f88 <+200>: mov 0x8(%rax),%rax
>>>> 0x00007f6080c97f8c <+204>: add $0x1,%rdx
>>>> 0x00007f6080c97f90 <+208>: test %rax,%rax
>>>> ...
>>>> (gdb) info registers
>>>> rax 0x10 16
>>>> rbx 0x7f5ff800ad30 140050159414576
>>>> rcx 0x10 16
>>>> rdx 0x0 0
>>>> rsi 0x2 2
>>>> rdi 0x1cfe570 30401904
>>>> rbp 0x7f607c3ecb80 0x7f607c3ecb80
>>>> rsp 0x7f607c3ecb50 0x7f607c3ecb50
>>>> r8 0x7f5ff80ae320 140050160083744
>>>> r9 0x7f5ff8052480 140050159707264
>>>> r10 0x0 0
>>>> r11 0x400 1024
>>>> r12 0x1cfe570 30401904
>>>> r13 0x7f6081419470 140052462146672
>>>> r14 0x2 2
>>>> r15 0x7f6081418640 140052462143040
>>>> rip 0x7f6080c97f88 0x7f6080c97f88
>>>> <SpaceManager::~SpaceManager()+200>
>>>> eflags 0x206 [ PF IF ]
>>>> cs 0x33 51
>>>> ss 0x2b 43
>>>> ds 0x0 0
>>>> es 0x0 0
>>>> fs 0x0 0
>>>> gs 0x0 0
>>>> k0 <unavailable>
>>>> k1 <unavailable>
>>>> k2 <unavailable>
>>>> k3 <unavailable>
>>>> k4 <unavailable>
>>>> k5 <unavailable>
>>>> k6 <unavailable>
>>>> k7 <unavailable>
>>>> -----------------------------------------------------------------------------
>>>>
>>>>
>>>> =============================================================================
>>>>
>>>>
>>>>
>>>>
>>>> Does anyone know about this case?
>>>>
>>>> Thanks, Osamu
>>>>
>>>>
>>
More information about the hotspot-gc-dev
mailing list