https://bugzilla.redhat.com/show_bug.cgi?id=1304591
--- Comment #7 from Florian Weimer <[email protected]> --- For me, just running the Go command itself results in a crash: (gdb) r Starting program: /usr/bin/go Missing separate debuginfos, use: dnf debuginfo-install golang-bin-1.6-0.3.rc1.fc24.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7de1be5 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2 (gdb) bt #0 0x00007ffff7de1be5 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2 #1 0x00007ffff7de6ea4 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2 #2 0x00007ffff7def2af in _dl_runtime_resolve_sse () from /lib64/ld-linux-x86-64.so.2 #3 0x0000000000829a9c in x_cgo_mmap () #4 0x0000000000000000 in ?? () → So it crashes extremely early in the process, in the dynamic linker. (gdb) disassemble Dump of assembler code for function _dl_lookup_symbol_x: 0x00007ffff7de1b60 <+0>: push %rbp 0x00007ffff7de1b61 <+1>: mov %rsp,%rbp 0x00007ffff7de1b64 <+4>: push %r15 0x00007ffff7de1b66 <+6>: push %r14 … 0x00007ffff7de1bdb <+123>: test %r12,%r12 0x00007ffff7de1bde <+126>: mov %rax,-0xa0(%rbp) => 0x00007ffff7de1be5 <+133>: movaps %xmm0,-0x90(%rbp) 0x00007ffff7de1bec <+140>: je 0x7ffff7de1bfb <_dl_lookup_symbol_x+155> 0x00007ffff7de1bee <+142>: testl $0xfffffffa,0x10(%rbp) 0x00007ffff7de1bf5 <+149>: jne 0x7ffff7de2c9b <_dl_lookup_symbol_x+4411> → The crash is at an SSE2 instruction. These typically have alignment requirements (the addresses must be a multiple of 16). Its a store onto the stack, so the most likely explanation is that the stack is misaligned. (gdb) print/x $rbp $4 = 0x7fffffffe1c8 → Yep, not a multiple of 16. Lets see where this comes from. (gdb) break x_cgo_mmap Breakpoint 1 at 0x829a90 (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/bin/go [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, 0x0000000000829a90 in x_cgo_mmap () (gdb) disassemble Dump of assembler code for function x_cgo_mmap: => 0x0000000000829a90 <+0>: sub $0x8,%rsp 0x0000000000829a94 <+4>: mov %r9d,%r9d 0x0000000000829a97 <+7>: callq 0x829d40 <mmap@plt> 0x0000000000829a9c <+12>: cmp $0xffffffffffffffff,%rax 0x0000000000829aa0 <+16>: je 0x829ab0 <x_cgo_mmap+32> 0x0000000000829aa2 <+18>: add $0x8,%rsp 0x0000000000829aa6 <+22>: retq 0x0000000000829aa7 <+23>: nopw 0x0(%rax,%rax,1) 0x0000000000829ab0 <+32>: callq 0x829bd0 <__errno_location@plt> 0x0000000000829ab5 <+37>: movslq (%rax),%rax 0x0000000000829ab8 <+40>: add $0x8,%rsp 0x0000000000829abc <+44>: retq End of assembler dump. (gdb) print $rsp $1 = (void *) 0x7fffffffe320 → This is incorrect. On function entry, %rsp + 8 must be a multiple of 16. Lets go up further the call stack. (gdb) up #1 0x00000000004e8f35 in runtime.callCgoMmap () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:269 269 CALL AX (gdb) disassemble Dump of assembler code for function runtime.callCgoMmap: 0x00000000004e8f10 <+0>: mov 0x8(%rsp),%rdi 0x00000000004e8f15 <+5>: mov 0x10(%rsp),%rsi 0x00000000004e8f1a <+10>: mov 0x18(%rsp),%edx 0x00000000004e8f1e <+14>: mov 0x1c(%rsp),%ecx 0x00000000004e8f22 <+18>: mov 0x20(%rsp),%r8d 0x00000000004e8f27 <+23>: mov 0x24(%rsp),%r9d 0x00000000004e8f2c <+28>: mov 0x78b225(%rip),%rax # 0xc74158 <_cgo_mmap> 0x00000000004e8f33 <+35>: callq *%rax => 0x00000000004e8f35 <+37>: mov %rax,0x28(%rsp) 0x00000000004e8f3a <+42>: retq 0x00000000004e8f3b <+43>: int3 0x00000000004e8f3c <+44>: int3 0x00000000004e8f3d <+45>: int3 0x00000000004e8f3e <+46>: int3 0x00000000004e8f3f <+47>: int3 End of assembler dump. (gdb) → This is a hand-written assembly routine. It is called with a correctly aligned %rsp. But then, it calls another function without making sure that this function, in turn, has %rsp + 8 as a multiple of 16 when entered. So, in short, this is a Go bug in the hand-written assembler code used as part of cgo. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ golang mailing list [email protected] http://lists.fedoraproject.org/admin/lists/[email protected]
