cmd/ld: broken when parsing LOCALS of a redefined hash function

[gopherbot]

by davyzhang:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
sorry, it's a big code base I didn't narrow it down

What is the expected output?

What do you see instead?

Which compiler are you using (5g, 6g, 8g, gccgo)?

Which operating system are you using?
macos 10.8.3

Which version are you using?  (run 'go version')
go version devel +86d952ac0976 Fri Mar 22 01:27:55 2013 +0100 darwin/amd64

Please provide any additional information below.
I upload the stacktrace log wish this could help

Attachments:

1. trace.log.7z (58013 bytes)

[bradfitz]

Comment 1:

Sorry, this doesn't give us much to work with.
Even after figuring out how to read a *.7z file, the strace-looking output doesn't have
anything obviously wrong with it.
I see some blocks of:
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
select(0x0, 0x0, 0x0, 0x0, 0xB0080A48)           = 0 0
... which looks a bit weird.  But there's still activity going on also.
Please try to narrow down the test case.

Status changed to WaitingForReply.

[davecheney]

Comment 2:

I think the select(...)s are the runtime.nanosleep behaviour of the
new scheduler.

[gopherbot]

Comment 3 by davyzhang:

sorry for the .7z file I upload a zip version wish this could be more convenient.
There's segment fault in the trace file and errors looks like
go build testmain: signal: segmentation fault
FAIL    starter [build failed]
write(0x2, "go build testmain: signal: segmentation fault\n\0", 0x2E)            = 46 0
I will try to narrow it down

Attachments:

1. trace.log.zip (76065 bytes)

[davecheney]

Comment 4:

Are you sure you are tracing the right program? I think you are tracing the go program,
not the test binary it forks.
I'd suggest using go test -c, the running the $PKG.test binary directly under
dtrace/strace/truss/whatever.

[gopherbot]

Comment 5 by davyzhang:

it looks the compiler's segment fault,  I can't build the code using -c
/Volumes/MacintoshHD/Users/xxx/Documents/workspace/work/dev/libs/go/bin/go test -c
warning: building out-of-date packages:
    darkhutgame.com/conf
    darkhutgame.com/timeutil
    darkhutgame.com/uuid
    darkhutgame.com/diskcache
    config
    code.google.com/p/goprotobuf/proto
    darkhutgame.com/server/codec
    darkhutgame.com/server
    darkhutgame.com/util
    shared/cmdtable
    shared/messageUp
    logic
    data
    shared/messageDown
    login
installing these packages with 'go test -i' will speed future tests.
go build testmain: signal: segmentation fault

[gopherbot]

Comment 6 by davyzhang:

finally I narrow it down :D
see the attachment can reproduce the problem
cd in package logic 
go test
warning: building out-of-date packages:
    shared/cmdtable
installing these packages with 'go test -i' will speed future tests.
go build testmain: signal: segmentation fault
FAIL    logic [build failed]

Attachments:

1. src.zip (1059 bytes)

[gopherbot]

Comment 7 by davyzhang:

Just a notice, this code can be compiled with the tip version 2 days ago. And fine with
the release version 1.0.3
The broken point is fmt.Printf("%d",len(cmdtable.CMDTable)) line:9 in logic/cmd.go
if I try to move the cmdtable package to local like this 
const (
    PlayGame = "PlayGame"
    Reg      = "Reg"
)
var CMDTable = [2]string{Reg, PlayGame}
func NewGetter()  {
    fmt.Printf("%d",len(CMDTable))
}
it will be fine

[davecheney]

Comment 8:

I can reproduce the problem under 10.7.5
odessa(~/Downloads) % go test -x -v ./...
WORK=/var/folders/7q/5n_khbqj5z716gk0zvtywgv80000gn/T/go-build625548197
mkdir -p $WORK/logic/_test/
mkdir -p $WORK/shared/cmdtable/_obj/
mkdir -p $WORK/shared/
cd /Users/dfc/Downloads/src/shared/cmdtable
/Users/dfc/go/pkg/tool/darwin_amd64/6g -o $WORK/shared/cmdtable/_obj/_go_.6 -p
shared/cmdtable -complete -D _/Users/dfc/Downloads/src/shared/cmdtable -I $WORK
./table.go
/Users/dfc/go/pkg/tool/darwin_amd64/pack grcP $WORK $WORK/shared/cmdtable.a
$WORK/shared/cmdtable/_obj/_go_.6
cd /Users/dfc/Downloads/src/logic
/Users/dfc/go/pkg/tool/darwin_amd64/6g -o $WORK/logic/_test/_go_.6 -p logic -complete -D
_/Users/dfc/Downloads/src/logic -I $WORK -I /Users/dfc/Downloads/pkg/darwin_amd64
./cmd.go ./cmd_test.go
/Users/dfc/go/pkg/tool/darwin_amd64/pack grcP $WORK $WORK/logic/_test/logic.a
$WORK/logic/_test/_go_.6
cd $WORK/logic/_test
/Users/dfc/go/pkg/tool/darwin_amd64/6g -o ./_go_.6 -p testmain -complete -D  -I . -I
$WORK ./_testmain.go
/Users/dfc/go/pkg/tool/darwin_amd64/pack grcP $WORK ./main.a ./_go_.6
cd .
/Users/dfc/go/pkg/tool/darwin_amd64/6l -o $WORK/logic/_test/logic.test -L
$WORK/logic/_test -L $WORK -L /Users/dfc/Downloads/pkg/darwin_amd64
$WORK/logic/_test/main.a
go build testmain: signal: segmentation fault

Status changed to Accepted.

[dvyukov]

Comment 9:

AddressSanitizer says:
==26089==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000034 (pc
0x000000483192 sp 0x7fffd9afb060 bp 0x7fffd9afb790 T0)
AddressSanitizer can not provide additional info.
    #0 0x483191 in ldobj1 src/cmd/6l/obj.c:600
    #1 0x46976e in ldobj src/cmd/6l/../ld/lib.c:804
    #2 0x468dc0 in objfile src/cmd/6l/../ld/lib.c:466
    #3 0x468395 in loadlib src/cmd/6l/../ld/lib.c:302
    #4 0x482028 in p9main src/cmd/6l/obj.c:265
    #5 0x4a5ec5 in main src/lib9/main.c:55
    #6 0x7ff5be68476c in __libc_start_main libc-start.c:226

[remyoudompheng]

Comment 10:

The linker fails on the duplicate definition of hash<[2]string>
$ cat a.go
package a
var A [2]string
$ go tool 6g a.go
$ cat b.go
package main
import "./a"
var B [2]string
func main() {
      println(a.A[0], B[1])
}
$ go tool 6g b.go
$ go tool 6l b.6
go tool 6l: signal: segmentation fault (core dumped)

[ianlancetaylor]

Comment 11:

Labels changed: added priority-soon, go1.1, removed priority-triage.

[ality]

Comment 12:

Rémy, are you working on this? If not, I can send out a CL. The fix is pretty simple.

[remyoudompheng]

Comment 13:

Yes https://golang.org/cl/7965043/
Does it LGTY?

[remyoudompheng]

Comment 14:

This issue was closed by revision d815a147187c0237a81e84e39035f6275b3fee4.

Status changed to Fixed.