runtime: invalid heap pointer found in bss on openbsd/386

[rsc]

The program being run is the new Go compiler written in Go,
but it's compiled against Go 1.4, hence the runtime sources with .c extensions.
If someone can get onto the openbsd/386 builder it should work to just
grab the new8g binary and look to see what address 8363f80 (or whatever
the binary prints) is in the nm output.

Probably an openbsd/386 runtime bug.

http://build.golang.org/log/1f001aa4bdcc36cadb2eaa79b82d5d2bc03fd0ae

# cmd/internal/gc
runtime: garbage collector found invalid heap pointer *(0x8363f80+0x170)=0x48392000 s=nil
fatal error: invalid heap pointer

runtime stack:
runtime.throw(0x834fc63)
    /tmp/buildlet-scatch722227927/src/runtime/panic.go:491 +0x83 fp=0xcfbe25e8 sp=0xcfbe25d0
scanblock(0x8363f80, 0xc7c0, 0x4834e9c8)
    /tmp/buildlet-scatch722227927/src/runtime/mgc0.c:378 +0x487 fp=0xcfbe2688 sp=0xcfbe25e8
markroot(0x1850c050, 0x1)
    /tmp/buildlet-scatch722227927/src/runtime/mgc0.c:496 +0x133 fp=0xcfbe26c0 sp=0xcfbe2688
runtime.parfordo(0x1850c050)
    /tmp/buildlet-scatch722227927/src/runtime/parfor.c:76 +0x93 fp=0xcfbe271c sp=0xcfbe26c0
gc(0xcfbe2858)
    /tmp/buildlet-scatch722227927/src/runtime/mgc0.c:1439 +0x1ef fp=0xcfbe2848 sp=0xcfbe271c
runtime.gc_m()
    /tmp/buildlet-scatch722227927/src/runtime/mgc0.c:1368 +0xb4 fp=0xcfbe2868 sp=0xcfbe2848
runtime.onM(0x8364c98)
    /tmp/buildlet-scatch722227927/src/runtime/asm_386.s:266 +0x4b fp=0xcfbe286c sp=0xcfbe2868
runtime.mstart()
    /tmp/buildlet-scatch722227927/src/runtime/proc.c:818 fp=0xcfbe2870 sp=0xcfbe286c

[rsc]

Similar (probably same) crash on windows/386.

http://build.golang.org/log/748faf9891dc31268e8757abb5718ad2b91d70d6

# cmd/internal/gc
runtime: garbage collector found invalid heap pointer *(0x730ec0+0xbec)=0x328f0000 s=nil
fatal error: invalid heap pointer

runtime stack:
runtime.throw(0x71cae3)
    C:/workdir/src/runtime/panic.go:491 +0x83 fp=0xcfc68 sp=0xcfc50
scanblock(0x730ec0, 0xe960, 0x17c9c8)
    C:/workdir/src/runtime/mgc0.c:378 +0x48d fp=0xcfd08 sp=0xcfc68
markroot(0x122cc140, 0x1)
    C:/workdir/src/runtime/mgc0.c:496 +0x139 fp=0xcfd40 sp=0xcfd08
runtime.parfordo(0x122cc140)
    C:/workdir/src/runtime/parfor.c:76 +0x99 fp=0xcfd9c sp=0xcfd40
gc(0xcfed8)
    C:/workdir/src/runtime/mgc0.c:1439 +0x1fb fp=0xcfec8 sp=0xcfd9c
runtime.gc_m()
    C:/workdir/src/runtime/mgc0.c:1368 +0xd2 fp=0xcfee8 sp=0xcfec8
runtime.onM(0x731df8)
    C:/workdir/src/runtime/asm_386.s:266 +0x50 fp=0xcfeec sp=0xcfee8
runtime.mstart()
    C:/workdir/src/runtime/proc.c:818 fp=0xcfef0 sp=0xcfeec

[randall77]

Might be related to #9872 . If that symbol is runtime.buckhash, the chance of relatedness goes up 10x.

[rsc]

Thanks Keith. Will ask Brad to update those builders to Go 1.4.2 and see if that fixes it.

[bradfitz]

Will do. (Russ, ignore my earlier question about which bug. I see this now.)

[mattn]

I got same problem on my environment(win32). but fixed with upgrading bootstrap-base of go to 1.4.2.

[adg]

@bradfitz did it fix it?

[bradfitz]

The builder's go1.4-openbsd-386.tar.gz was last updated on Feb 23, 2015.
Likewise with go1.4-windows-386.tar.gz.

So the builders are happy now.

Removed the Go 1.4.3 label from this.