i386 Go programs crash on amd64

[Peter Jeremy]

On 2014-May-26 16:44:57 +0300, Konstantin Belousov <kostikbel at gmail.com> wrote:
>On Mon, May 26, 2014 at 09:36:22PM +1000, Peter Jeremy wrote:
>> On 2014-May-24 10:41:01 +0300, Konstantin Belousov <kostikbel at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 964 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20140529/67fa38e2/attachment.sig>