https://bugzilla.redhat.com/show_bug.cgi?id=1304591
--- Comment #8 from Jakub Čajka <[email protected]> --- (In reply to Florian Weimer from comment #7) > 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. Already there, too :), unfortunately got some unexpected distraction yesterday, requiring my immediate attention..., hopefully I will have fix today... -- 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]
