gopack: segmentation fault in runtime

[gopherbot]

by ninkendo:

This is on a University server (I'm the admin) and I'm trying to get Go 
working on an NFS mount so all our Ubuntu servers can have the go compiler 
on it (so students can play around with it.)

I can consistently compile Go from a directory like /tmp or /usr/src, but 
cloning the hg tree to a NFS-mounted direcory always results in a segfault.

What steps will reproduce the problem?
1. Clone the mercurial tree to an NFS filesystem
2. Set GOBIN to any directory, on or off NFS
3. cd to $GOROOT/src and run ./all.bash

What is the expected output? What do you see instead?

Expected build to perform the same as it does on non-nfs filesystems.

Instead, get the following:

gopack grc _obj/runtime.a _go_.6 asm.6 cgocall.6 chan.6 closure.6 float.6 
hashmap.6 iface.6 malloc.6 mcache.6 mcentral.6 mem.6 mfixalloc.6 mgc0.6 
mheap.6 mheapmap64.6 msize.6 print.6 proc.6 reflect.6 rune.6 runtime.6 
rt0.6 sema.6 signal.6 slice.6 string.6 symtab.6 sys.6 thread.6 traceback.6
make[1]: *** [_obj/runtime.a] Segmentation fault
rm reflect.c string.c sema.c malloc.c
make[1]: Leaving directory `/nfs/apps/go/src/pkg/runtime'
make: *** [runtime.install] Error 2

I can reliably reproduce the segfault from $GOROOT/src/pkg/runtime and 
running the above gopack command.


What is your $GOOS?  $GOARCH?
linux, amd64

(Ubuntu 8.04.3 LTS, kernel 2.6.24-24-server)

Which revision are you sync'ed to?  (hg log -l 1)

changeset:   3975:b51fd2d6c160

Please provide any additional information below.

strace dump is included.  It looks like it's segfaulting trying to talk to 
winbind for user authentication?  Not sure if gopack is doing any of this, 
or if it's library code... but it reliably works when $GOROOT is on a local 
filesystem.

Attachments:

1. strace.txt (9011 bytes)

[rsc]

Comment 2:

Issue #57 has been merged into this issue.

[rsc]

Comment 3:

Status changed to Accepted.

[rsc]

Comment 4:

Owner changed to r...@golang.org.

[rsc]

Comment 5:

Status changed to Started.

[gopherbot]

Comment 6 by b88zhou:

gopack.strace for merged isssue 57

Attachments:

1. gopack.strace (10021 bytes)

[rsc]

Comment 7:

This issue was closed by revision a174987.

Status changed to Fixed.

Merged into issue #-.

[gopherbot]

Comment 8 by b88zhou:

It does not fix the segfault under native arm build (originally raised in issue #57).

[rsc]

Comment 9:

b88zhou: please add the output of hg log -l 1
and also the output of running the gopack command
under strace.

Status changed to Started.

[gopherbot]

Comment 10 by b88zhou:

$ hg log -l 1
changeset:   3992:14daa3d2c998
tag:         tip
user:        Russ Cox <rsc@golang.org>
date:        Wed Nov 11 14:51:53 2009 -0800
summary:     point at how to get easy_install on Ubuntu.

Attachments:

1. gopack.strace (4856 bytes)

[rsc]

Comment 11:

Thanks.  This is definitely different.
Can you please run gopack under gdb and try to get a stack trace?

[gopherbot]

Comment 12 by b88zhou:

bt output

Attachments:

1. gopack-gdb-bt.txt (2046 bytes)

[rsc]

Comment 13:

ninkendo: did the fix solve your gopack problem?
(You'll have to hg pull -u to get an updated tree.)
b88zhou: I have been through the relevant code again
and cannot see how that trace can happen.  It looks
like in duplicate, p->name is 0, which should not be
possible.  If you have experience with C and want to
try to figure it out, it's a very simple hash table
somehow gone awry.

Status changed to Accepted.

[rsc]

Comment 14:

Status changed to WaitingForReply.

[gopherbot]

Comment 15 by b88zhou:

$ cat hashstr.c
#include <stdio.h>
int
hashstr(char *name)
{
    int h;
    char *cp;
    h = 0;
    for (cp = name; *cp; h += *cp++)
        h *= 1119;
    printf("before h=%d\n", h);
    if (h < 0)
        h = ~h;
    printf("after h=%d\n", h);
    return h;
}
int
main(void) {
    int n, h;
    n = hashstr("breakpoint");
    h = n % 1024;
    printf("hashstr=%d h=%d\n", n, h);
}
$ gcc-4.3 -g -o hashstr hashstr.c
$ ./hashstr
before h=-585750607
after h=585750606
hashstr=585750606 h=78
$ gcc-4.3 -g -O2 -fno-inline -o hashstr hashstr.c
$ ./hashstr
before h=-585750607
after h=-585750607
hashstr=-585750607 h=-79
$ gcc-4.4 -g -o hashstr hashstr.c
$ ./hashstr
before h=-585750607
after h=585750606
hashstr=585750606 h=78
Looks like a gcc 4.3 specific bug when using -O2. Reproducible on two NAS devices.

[rsc]

Comment 16:

Nice bug!  Thanks for tracking that down.
I'd like to find a workaround rather than require
people to use a different gcc.
Instead of if(h < 0) h = ~h, does it work
if you use if(h < 0) h = (unsigned)h>>1
?
Thanks.

[gopherbot]

Comment 17 by b88zhou:

Tried your suggestion, does not work.
My guess is that gcc 4.3 -O2 optimized away (h < 0) as always false.
The following seems to work:
int
hashstr(char *name)
{
    unsigned int h;
    char *cp;
    h = 0;
    for (cp = name; *cp; h += *cp++)
        h *= 1119;
    if (h & (0x01 << 31))
        h = ~h;
    return (int) h;
}
During native build, gopak no longer segfaults. I had a different problem now, I'll 
file a separate issue. Thanks.

[rsc]

Comment 18:

I'm going to do something a little simpler,
just in case int is 64 bits.  Thanks for tracking it down.
I'd never have guessed that.

Status changed to Started.

[rsc]

Comment 19:

Fixed by http://golang.org/cl/152088

Status changed to Fixed.

[gopherbot]

Comment 20 by ninkendo:

I can confirm that the latest hg tree builds on my nfs filesystem, and this issues is 
now fixed.