Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Hi Zhengyu, Thanks for your patch! I will backport it to jdk8u and test it for X86 and mips64el. Thanks, Leslie Zhai 在 2018年09月12日 20:58, Zhengyu Gu 写道: Probably should also backport the followup RFE: https://bugs.openjdk.java.net/browse/JDK-8206183 Thanks, -Zhengyu On 09/11/2018 10:58 PM, David Holmes wrote: Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Hi Leslie,
The problem really lies in the OpenJDK code, as it is attempting to
write to a const object. If this seems to work with certain compiler(s)
and optimization settings, it is just luck. :-)
Here is a reduced example, which shows the issue:
==
#include
class NativeCallStack {
public:
static const NativeCallStack EMPTY_STACK;
private:
enum { DEPTH = 4 };
void* stack[DEPTH];
public:
NativeCallStack() {
for (int i = 0; i < DEPTH; ++i) {
stack[i] = nullptr;
}
}
};
const NativeCallStack NativeCallStack::EMPTY_STACK;
int main(void)
{
// The following should segfault, if EMPTY_STACK was placed into .rodata.
::new ((void*)::EMPTY_STACK) NativeCallStack();
return 0;
}
==
clang 7.0.0 rc2 produces this assembly:
.globl main# -- Begin function main
.p2align4, 0x90
.type main,@function
main: # @main
.cfi_startproc
# %bb.0:# %entry
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
xorps %xmm0, %xmm0
movups %xmm0, NativeCallStack::EMPTY_STACK+16(%rip)
movups %xmm0, NativeCallStack::EMPTY_STACK(%rip)
xorl%eax, %eax
popq%rbp
.cfi_def_cfa %rsp, 8
retq
.Lfunc_end0:
.size main, .Lfunc_end0-main
.cfi_endproc
# -- End function
.type NativeCallStack::EMPTY_STACK,@object #
@NativeCallStack::EMPTY_STACK
.section.rodata,"a",@progbits
.globl NativeCallStack::EMPTY_STACK
.p2align3
NativeCallStack::EMPTY_STACK:
.zero 32
.size NativeCallStack::EMPTY_STACK, 32
The whole constructor has been optimized out, and EMPTY_STACK has been
replaced by .zero 32, placed in the .rodata segment, which is a
perfectly valid transformation.
Then, in main(), an attempt is made to write to that read-only segment,
which will usually segfault, depending on how strictly the underlying
operating system enforces these protections.
In contrast, gcc 8.2.0 produces:
.globl main
.type main, @function
main:
.LFB74:
.cfi_startproc
movq$0, NativeCallStack::EMPTY_STACK(%rip)
xorl%eax, %eax
movq$0, NativeCallStack::EMPTY_STACK+8(%rip)
movq$0, NativeCallStack::EMPTY_STACK+16(%rip)
movq$0, NativeCallStack::EMPTY_STACK+24(%rip)
ret
.cfi_endproc
.LFE74:
.size main, .-main
.p2align 4,,15
.type _GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE, @function
_GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE:
.LFB76:
.cfi_startproc
movq$0, NativeCallStack::EMPTY_STACK(%rip)
movq$0, NativeCallStack::EMPTY_STACK+8(%rip)
movq$0, NativeCallStack::EMPTY_STACK+16(%rip)
movq$0, NativeCallStack::EMPTY_STACK+24(%rip)
ret
.cfi_endproc
.LFE76:
.size _GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE,
.-_GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE
.section.ctors,"aw",@progbits
.align 8
.quad _GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE
.globl NativeCallStack::EMPTY_STACK
.bss
.align 32
.type NativeCallStack::EMPTY_STACK, @object
.size NativeCallStack::EMPTY_STACK, 32
NativeCallStack::EMPTY_STACK:
.zero 32
Here you can see that gcc decided to not place EMPTY_STACK in .rodata,
but in .bss, which is read/write. It adds the global constructor to
the .ctors section, so the dynamic linker is made responsible for
calling it.
Note that now the EMPTY_STACK object is unnecessarily initialized twice,
once by the global constructor, and once in main.
-Dimitry
> On 11 Sep 2018, at 03:38, Leslie Zhai wrote:
>
> Hi Dimitry,
>
> Thanks for your kind response!
>
> Thanks for the commit message of Jung's patch, I found that the bug had been
> fixed in OpenJDK 12 by Zhengyu
> https://bugs.openjdk.java.net/browse/JDK-8205965 But only backported to 11.
> So Jung could backport it for OpenJDK 8, thanks a lot!
>
> But I argue that the root cause might be in the compiler side, why
> clang-3.9.1, gcc-6.4.1 couldn't reproduce the bug? And it might be work for
> clang-4.0 https://bugs.openjdk.java.net/browse/JDK-8208494 I will test LLVM
> 5 to check out whether or not reproducible.
>
>
> 在 2018年09月11日 00:59, Dimitry Andric 写道:
>> Hi Leslie,
>>
>> This is likely the same problem as was reported in
>> https://bugs.freebsd.org/225054#c8, and fixed by the following patch:
>>
>>
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Hi Leslie,
This is likely the same problem as was reported in
https://bugs.freebsd.org/225054#c8, and fixed by the following patch:
https://svnweb.freebsd.org/ports/head/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp?view=markup=459368
Can you please try that out, and see if it fixes it for you too?
-Dimitry
> On 10 Sep 2018, at 18:20, Leslie Zhai via llvm-dev
> wrote:
>
> Hi all,
>
> OpenJDK8 jdk8u-dev[1] is just able to work after compiled with LLVM 3.9.1 for
> X86:
>
> $ ./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java
> -version
> openjdk version "1.8.0-internal-debug"
> OpenJDK Runtime Environment (build
> 1.8.0-internal-debug-xiangzhai_2018_09_09_21_08-b00)
> OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode)
>
> $ strings
> ./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java |
> grep clang
> clang version 3.9.1 (tags/RELEASE_391/final)
>
> But it failed to work after compiled with LLVM 8 for X86:
>
> $ ./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
> -version
> Segmentation fault
>
> $ gdb --ex run --args
> ./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
> -version
> GNU gdb (GDB) Fedora 7.12.1-48.fc25
> ...
> Starting program:
> /home/xiangzhai/project/jdk8u-llvm/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
> -version
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> [ Legend: Modified register | Code | Heap | Stack | String ]
> ───[
> registers ]
> $rax : 0x0
> $rbx : 0x0
> $rcx : 0x77315eb0 → 0x76ae30a0 →
> xor edx, edx
> $rdx : 0x0
> $rsp : 0x7fff9328 → 0x76a76822 →
> mov edi, ebx
> $rbp : 0x7fff93c0 → 0x7fff94f0 → 0x7fff9510 →
> 0x0002
> $rsi : 0x0
> $rdi : 0x77315e70 → 0x77315eb0 → 0x76ae30a0 →
> xor edx, edx
> $rip : 0x76ae2f5b → mov
> QWORD PTR [rdi], rcx
> $r8: 0x1
> $r9: 0xf
> $r10 : 0x64
> $r11 : 0x0
> $r12 : 0x7fffdc88 → 0x7fffe04c →
> "/home/xiangzhai/project/jdk8u-llvm/build/linux-x86[...]"
> $r13 : 0x7fffdca0 → 0x7fffe0bf → "XDG_VTNR=1"
> $r14 : 0x7fff9330 → "NMT_LEVEL_10535"
> $r15 : 0x6
> $eflags: [carry parity adjust zero sign trap INTERRUPT direction overflow
> RESUME virtualx86 identification]
> $ss: 0x002b $ds: 0x $cs: 0x0033 $es: 0x $gs: 0x $fs: 0x
> ───[
> stack ]
> 0x7fff9328│+0x00: 0x76a76822 →
> mov edi, ebx← $rsp
> 0x7fff9330│+0x08: "NMT_LEVEL_10535" ← $r14
> 0x7fff9338│+0x10: 0x0035333530315f4c ("L_10535"?)
> 0x7fff9340│+0x18: 0x0001
> 0x7fff9348│+0x20: 0x00602190 → 0x75eb7000 →
> 0x00010102464c457f
> 0x7fff9350│+0x28: 0x0004
> 0x7fff9358│+0x30: 0x00066474e551
> 0x7fff9360│+0x38: 0x
> [
> code:i386:x86-64 ]
>0x76ae2f4b addeax,
> 0x1f0f00
>0x76ae2f50 movrcx, QWORD
> PTR [rip+0x842781]# 0x773256d8
>0x76ae2f57 addrcx, 0x10
> → 0x76ae2f5b movQWORD PTR
> [rdi], rcx
>0x76ae2f5e movDWORD PTR
> [rdi+0x28], 0x0
>0x76ae2f65 addrdi, 0x8
>0x76ae2f69 test edx, edx
>0x76ae2f6b je
> 0x76ae2f7b
>0x76ae2f6d moveax, esi
> ─[
> source:/home/xiangzhai/project/jdk8u-llvm/hotspot/src/share/vm/utilities/nativeCallStack.cpp+33
> ]
> 28 #include "utilities/nativeCallStack.hpp"
> 29
> 30 const NativeCallStack NativeCallStack::EMPTY_STACK(0, false);
> 31
> 32 NativeCallStack::NativeCallStack(int toSkip, bool fillStack) :
> → 33_hash_value(0) {
> 34
> 35 #if !PLATFORM_NATIVE_STACK_WALKING_SUPPORTED
> 36fillStack = false;
> 37 #endif
> 38
> ─[
> threads ]
> [#0] Id 1, Name: "java", stopped, reason: SIGSEGV
> ───[
> trace ]
> [#0] 0x76ae2f5b → Name:
> NativeCallStack::NativeCallStack(this=0x77315e70
> , toSkip=0x0, fillStack=0x0)
> [#1] 0x76a76822 → Name: MemTracker::init_tracking_level()
> [#2] 0x762eff49 → Name: MemTracker::tracking_level()
> [#3] 0x762eff49 → Name: ResourceObj::operator new(size=0x20,
>
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Probably should also backport the followup RFE: https://bugs.openjdk.java.net/browse/JDK-8206183 Thanks, -Zhengyu On 09/11/2018 10:58 PM, David Holmes wrote: Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
On 12/09/2018 1:18 PM, Leslie Zhai wrote: Hi, Thanks for your kind response! 在 2018年09月12日 10:58, David Holmes 写道: Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 Already known :) http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023181.html But I want to find out which commit or review bring in the "issue" in the LLVM side: http://lists.llvm.org/pipermail/llvm-dev/2018-September/125994.html Continue that discussion with the llvm folk but the OpenJDK part of this has been addressed. Cheers, David David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Hi, Thanks for your kind response! 在 2018年09月12日 10:58, David Holmes 写道: Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 Already known :) http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023181.html But I want to find out which commit or review bring in the "issue" in the LLVM side: http://lists.llvm.org/pipermail/llvm-dev/2018-September/125994.html David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m -- Regards, Leslie Zhai
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Or to be a little less obscure, this is a known issue and you should look into backporting: https://bugs.openjdk.java.net/browse/JDK-8205965 David On 12/09/2018 5:03 AM, Martin Buchholz wrote: https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Hi Dimitry, Thank you so much for the reduced testcase! It is able to reproduce after compiled with clang-8 optimized for X86: $ clang++ -O3 -S -c JDK-8205969.cpp -o JDK-8205969-opt-8.0.s $ clang++ -O3 -c JDK-8205969.cpp -o JDK-8205969-opt-8.0.o $ clang++ -o JDK-8205969-opt-8.0.out JDK-8205969-opt-8.0.o $ ./JDK-8205969-opt-8.0.out Segmentation fault $ cat JDK-8205969-opt-8.0.s .text .file "JDK-8205969.cpp" .globl main # -- Begin function main .p2align 4, 0x90 .type main,@function main: # @main .cfi_startproc # %bb.0: xorps %xmm0, %xmm0 movups %xmm0, _ZN15NativeCallStack11EMPTY_STACKE+16(%rip) movups %xmm0, _ZN15NativeCallStack11EMPTY_STACKE(%rip) xorl %eax, %eax retq .Lfunc_end0: .size main, .Lfunc_end0-main .cfi_endproc # -- End function .type _ZN15NativeCallStack11EMPTY_STACKE,@object # @_ZN15NativeCallStack11EMPTY_STACKE .section .rodata,"a",@progbits ^--- READ-ONLY segment .globl _ZN15NativeCallStack11EMPTY_STACKE .p2align 3 _ZN15NativeCallStack11EMPTY_STACKE: .zero 32 .size _ZN15NativeCallStack11EMPTY_STACKE, 32 .ident "LLVM China clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 81ef98628ebf5186d746c0986dcbf5073e842043) (g...@github.com:llvm-mirror/llvm.git e1aac9723d55497e74d83d216329f08d9842e494) (based on LLVM 8.0.0svn)" .section ".note.GNU-stack","",@progbits .addrsig But it is *not* able to reproduce with clang-8 not optimized for X86: $ clang++ -O0 -S -c JDK-8205969.cpp -o JDK-8205969-unopt-8.0.s $ clang++ -O0 -c JDK-8205969.cpp -o JDK-8205969-unopt-8.0.o $ clang++ -o JDK-8205969-unopt-8.0.out JDK-8205969-unopt-8.0.o $ ./JDK-8205969-unopt-8.0.out No segfault $ cat JDK-8205969-unopt-8.0.s .text .file "JDK-8205969.cpp" .section .text.startup,"ax",@progbits .p2align 4, 0x90 # -- Begin function __cxx_global_var_init .type __cxx_global_var_init,@function __cxx_global_var_init: # @__cxx_global_var_init .cfi_startproc # %bb.0: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp movabsq $_ZN15NativeCallStack11EMPTY_STACKE, %rdi callq _ZN15NativeCallStackC2Ev popq %rbp .cfi_def_cfa %rsp, 8 retq .Lfunc_end0: .size __cxx_global_var_init, .Lfunc_end0-__cxx_global_var_init .cfi_endproc # -- End function .section .text._ZN15NativeCallStackC2Ev,"axG",@progbits,_ZN15NativeCallStackC2Ev,comdat .weak _ZN15NativeCallStackC2Ev # -- Begin function _ZN15NativeCallStackC2Ev .p2align 4, 0x90 .type _ZN15NativeCallStackC2Ev,@function _ZN15NativeCallStackC2Ev: # @_ZN15NativeCallStackC2Ev .cfi_startproc # %bb.0: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp movq %rdi, -8(%rbp) movq -8(%rbp), %rdi movl $0, -12(%rbp) movq %rdi, -24(%rbp) # 8-byte Spill .LBB1_1: # =>This Inner Loop Header: Depth=1 cmpl $4, -12(%rbp) jge .LBB1_4 # %bb.2: # in Loop: Header=BB1_1 Depth=1 movslq -12(%rbp), %rax movq -24(%rbp), %rcx # 8-byte Reload movq $0, (%rcx,%rax,8) # %bb.3: # in Loop: Header=BB1_1 Depth=1 movl -12(%rbp), %eax addl $1, %eax movl %eax, -12(%rbp) jmp .LBB1_1 .LBB1_4: popq %rbp .cfi_def_cfa %rsp, 8 retq .Lfunc_end1: .size _ZN15NativeCallStackC2Ev, .Lfunc_end1-_ZN15NativeCallStackC2Ev .cfi_endproc # -- End function .text .globl main # -- Begin function main .p2align 4, 0x90 .type main,@function main: # @main .cfi_startproc # %bb.0: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp subq $16, %rsp movl $0, -4(%rbp) movabsq $_ZN15NativeCallStack11EMPTY_STACKE, %rdi callq _ZN15NativeCallStackC2Ev xorl %eax, %eax addq $16, %rsp popq %rbp .cfi_def_cfa %rsp, 8 retq .Lfunc_end2: .size main, .Lfunc_end2-main .cfi_endproc # -- End function
Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86
Hi Dimitry,
Thanks for your kind response!
Thanks for the commit message of Jung's patch, I found that the bug had
been fixed in OpenJDK 12 by Zhengyu
https://bugs.openjdk.java.net/browse/JDK-8205965 But only backported to
11. So Jung could backport it for OpenJDK 8, thanks a lot!
But I argue that the root cause might be in the compiler side, why
clang-3.9.1, gcc-6.4.1 couldn't reproduce the bug? And it might be work
for clang-4.0 https://bugs.openjdk.java.net/browse/JDK-8208494 I will
test LLVM 5 to check out whether or not reproducible.
在 2018年09月11日 00:59, Dimitry Andric 写道:
Hi Leslie,
This is likely the same problem as was reported in
https://bugs.freebsd.org/225054#c8, and fixed by the following patch:
https://svnweb.freebsd.org/ports/head/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp?view=markup=459368
Can you please try that out, and see if it fixes it for you too?
-Dimitry
On 10 Sep 2018, at 18:20, Leslie Zhai via llvm-dev
wrote:
Hi all,
OpenJDK8 jdk8u-dev[1] is just able to work after compiled with LLVM 3.9.1 for
X86:
$ ./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java
-version
openjdk version "1.8.0-internal-debug"
OpenJDK Runtime Environment (build
1.8.0-internal-debug-xiangzhai_2018_09_09_21_08-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode)
$ strings
./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java | grep
clang
clang version 3.9.1 (tags/RELEASE_391/final)
But it failed to work after compiled with LLVM 8 for X86:
$ ./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
-version
Segmentation fault
$ gdb --ex run --args
./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
-version
GNU gdb (GDB) Fedora 7.12.1-48.fc25
...
Starting program:
/home/xiangzhai/project/jdk8u-llvm/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
-version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
[ Legend: Modified register | Code | Heap | Stack | String ]
───[
registers ]
$rax : 0x0
$rbx : 0x0
$rcx : 0x77315eb0 → 0x76ae30a0 →
xor edx, edx
$rdx : 0x0
$rsp : 0x7fff9328 → 0x76a76822 →
mov edi, ebx
$rbp : 0x7fff93c0 → 0x7fff94f0 → 0x7fff9510 →
0x0002
$rsi : 0x0
$rdi : 0x77315e70 → 0x77315eb0 → 0x76ae30a0 →
xor edx, edx
$rip : 0x76ae2f5b → mov
QWORD PTR [rdi], rcx
$r8: 0x1
$r9: 0xf
$r10 : 0x64
$r11 : 0x0
$r12 : 0x7fffdc88 → 0x7fffe04c →
"/home/xiangzhai/project/jdk8u-llvm/build/linux-x86[...]"
$r13 : 0x7fffdca0 → 0x7fffe0bf → "XDG_VTNR=1"
$r14 : 0x7fff9330 → "NMT_LEVEL_10535"
$r15 : 0x6
$eflags: [carry parity adjust zero sign trap INTERRUPT direction overflow
RESUME virtualx86 identification]
$ss: 0x002b $ds: 0x $cs: 0x0033 $es: 0x $gs: 0x $fs: 0x
───[
stack ]
0x7fff9328│+0x00: 0x76a76822 →
mov edi, ebx← $rsp
0x7fff9330│+0x08: "NMT_LEVEL_10535" ← $r14
0x7fff9338│+0x10: 0x0035333530315f4c ("L_10535"?)
0x7fff9340│+0x18: 0x0001
0x7fff9348│+0x20: 0x00602190 → 0x75eb7000 →
0x00010102464c457f
0x7fff9350│+0x28: 0x0004
0x7fff9358│+0x30: 0x00066474e551
0x7fff9360│+0x38: 0x
[
code:i386:x86-64 ]
0x76ae2f4b addeax,
0x1f0f00
0x76ae2f50 movrcx, QWORD
PTR [rip+0x842781]# 0x773256d8
0x76ae2f57 addrcx, 0x10
→ 0x76ae2f5b movQWORD PTR
[rdi], rcx
0x76ae2f5e movDWORD PTR
[rdi+0x28], 0x0
0x76ae2f65 addrdi, 0x8
0x76ae2f69 test edx, edx
0x76ae2f6b je 0x76ae2f7b
0x76ae2f6d moveax, esi
─[
source:/home/xiangzhai/project/jdk8u-llvm/hotspot/src/share/vm/utilities/nativeCallStack.cpp+33
]
28 #include "utilities/nativeCallStack.hpp"
29
30 const NativeCallStack NativeCallStack::EMPTY_STACK(0, false);
31
32 NativeCallStack::NativeCallStack(int toSkip, bool fillStack) :
→ 33_hash_value(0) {
34
35 #if !PLATFORM_NATIVE_STACK_WALKING_SUPPORTED
36fillStack = false;
37 #endif
38
─[
threads ]
[#0] Id 1, Name: "java", stopped, reason: SIGSEGV
