On 2014-May-26 16:44:57 +0300, Konstantin Belousov <[email protected]> wrote: >On Mon, May 26, 2014 at 09:36:22PM +1000, Peter Jeremy wrote: >> On 2014-May-24 10:41:01 +0300, Konstantin Belousov <[email protected]> >> wrote: >> >> >Provide the minimal test case. >> >> >> >> The following go program, compiled on i386 and run on amd64 will die >> >> with a segmentation violation or bus error: >> >> ------- >> >> package main >> >> >> >> import "fmt" >> >> >> >> func main() { >> >> fmt.Println("Hello World") >> >> } >> >> ------- >> >No, this is not consumable. >> > >> >I need a self-contained minimal example written in C/asm. >> >> Actually, I've found that >> -------- >> package main >> import "syscall" >> func main() { syscall.Write(1, []byte("Hello World\n")) } >> -------- >> also crashes ~66 syscalls after the first sysarch(2) call. That >> reduces the binary to 520K (go reports this is 50K lines of assembler). >> >> >If this is too hard to produce, give the the self-contained >> >binary, again as small as possible (small by comparing the >> >number of syscalls before the issue manifests itself). >> >> I've uploaded the source, binary and disassembly to >> freefall:~peterj/write{.go,,.S} (and verified it crashes). >> >> If I get time, I'll see if I can strip some of the support code out of >> Go to shrink it further. > >What exactly do you mean by 'crashing' ?
I see it dying with either SIGBUS or SIGSEGV. On freefall, I see:
freefall% ./write
zsh: segmentation fault (core dumped) ./write
> I see some spills from (probably) Go runtime.
I've tried further experiments with different hardware and different
loading and get different results: Sometimes I get nothing other than
a coredump and an other times I get part or all of a runtime spill
similar to you. I suspect there may be multiple issues.
> I am not sure that this is something which should
>be looked at from the kernel side, at least initially.
As I wrote in my initial mail, I am not certain whether this is a problem
with Go or FreeBSD. And having done some poking at corefiles with gdb
(you need gdb7.6 from ports to grok the Go debug information), I have
found that all my programs are dying at:
mov %gs:0xfffffff8,%ecx
but it seems to be timing related as to when the offending instruction
is executed. I will do some further investigation into how segment
wraparound is handled.
> E.g., the 32bit
>binaries on amd64 have stack starting near the top of the address space,
>i.e. 4G - some amount. Could this be a problem for the Go ?
That seems unlikely but I guess it's a possibility.
--
Peter Jeremy
pgpfkvhsnfJdL.pgp
Description: PGP signature
