gopack: segmentation fault in runtime about go HOT 19 CLOSED

Comment 2:

Issue #57 has been merged into this issue.

from go.

Comment 3:

Status changed to Accepted.

from go.

Comment 4:

Owner changed to [email protected].

from go.

Comment 5:

Status changed to Started.

from go.

Comment 6 by b88zhou:

gopack.strace for merged isssue 57

Attachments:

1. gopack.strace (10021 bytes)

from go.

Comment 7:

This issue was closed by revision a174987.

Status changed to Fixed.

Merged into issue #-.

from go.

Comment 8 by b88zhou:

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

from go.

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.

from go.

Comment 10 by b88zhou:

$ hg log -l 1
changeset:   3992:14daa3d2c998
tag:         tip
user:        Russ Cox <[email protected]>
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)

from go.

Comment 11:

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

from go.

Comment 12 by b88zhou:

bt output

Attachments:

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

from go.

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.

from go.

Comment 14:

Status changed to WaitingForReply.

from go.

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.

from go.

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.

from go.

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.

from go.

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.

from go.

Comment 19:

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

Status changed to Fixed.

from go.

Comment 20 by ninkendo:

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

from go.