Skip to content

runtime: invalid heap pointer during GC on windows/386 #9015

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rsc opened this issue Oct 29, 2014 · 4 comments
Closed

runtime: invalid heap pointer during GC on windows/386 #9015

rsc opened this issue Oct 29, 2014 · 4 comments
Labels
FrozenDueToAge
Milestone
Go1.4

Comments

@rsc
Copy link
Contributor

rsc commented Oct 29, 2014 

windows/386 failure at CL 153240043 / hg c5ee3f481631.

http://build.golang.org/log/04f483224055ef6972746ab22c53271c05ce85b8

--- FAIL: TestLockedDeadlock-4 (0.03s)
    crash_test.go:72: failed to execute 'go list': exit status 2
        runtime: garbage collector found invalid heap pointer *(0x12454320+0x10)=0x12475fe4 span=0x12470000-0x0-0x12550000 state=2
        runtime: found *(0x12464000+0x14) = 0x12454320+0x0
        runtime: found *(0x12462000+0x4c) = 0x12464000+0x0
        runtime: found *(0x933d00+0x16a4) = 0x12462000+0x0
        fatal error: bad pointer
        
        runtime stack:
        runtime.throw(0x929b90)
            c:/go/src/runtime/panic.go:492 +0x83 fp=0xcfc68 sp=0xcfc50
        scanblock(0x933d00, 0x8fe0, 0x32c5c0)
            c:/go/src/runtime/mgc0.c:410 +0x759 fp=0xcfd08 sp=0xcfc68
        markroot(0x1245a190, 0x1)
            c:/go/src/runtime/mgc0.c:495 +0x139 fp=0xcfd40 sp=0xcfd08
        runtime.parfordo(0x1245a190)
            c:/go/src/runtime/parfor.c:91 +0x115 fp=0xcfd9c sp=0xcfd40
        gc(0xcfed8)
            c:/go/src/runtime/mgc0.c:1438 +0x1fb fp=0xcfec8 sp=0xcfd9c
        runtime.gc_m()
            c:/go/src/runtime/mgc0.c:1372 +0xe7 fp=0xcfee8 sp=0xcfec8
        runtime.onM(0x934d58)
            c:/go/src/runtime/asm_386.s:266 +0x50 fp=0xcfeec sp=0xcfee8
        runtime.mstart()
            c:/go/src/runtime/proc.c:786 fp=0xcfef0 sp=0xcfeec
        
        goroutine 1 [garbage collection, locked to thread]:
        runtime.switchtoM()
            c:/go/src/runtime/asm_386.s:208 fp=0x1246de88 sp=0x1246de84
        runtime.gogc(0x0)
            c:/go/src/runtime/malloc.go:469 +0x1aa fp=0x1246dea8 sp=0x1246de88
        runtime.mallocgc(0x20, 0x71fe00, 0x0, 0x0)
            c:/go/src/runtime/malloc.go:341 +0x2c4 fp=0x1246df00 sp=0x1246dea8
        runtime.newobject(0x71fe00, 0x1)
            c:/go/src/runtime/malloc.go:353 +0x48 fp=0x1246df14 sp=0x1246df00
        runtime.makemap(0x6c4d80, 0x0, 0x0, 0x0)
            c:/go/src/runtime/hashmap.go:220 +0x32e fp=0x1246df4c sp=0x1246df14
        unicode.init()
            c:/go/src/unicode/tables.go:52 +0x5c fp=0x1246df6c sp=0x1246df4c
        go/parser.init()
            c:/go/src/go/parser/parser.go:2462 +0x45 fp=0x1246df78 sp=0x1246df6c
        main.init()
            c:/go/src/cmd/go/zdefaultcc.go:6 +0x45 fp=0x1246dfcc sp=0x1246df78
        runtime.main()
            c:/go/src/runtime/proc.go:58 +0xbd fp=0x1246dff0 sp=0x1246dfcc
        runtime.goexit()
            c:/go/src/runtime/proc.c:1651 fp=0x1246dff4 sp=0x1246dff0
        
        goroutine 2 [runnable]:
        runtime.forcegchelper()
            c:/go/src/runtime/proc.go:90 fp=0x1246aff0 sp=0x1246afec
        runtime.goexit()
            c:/go/src/runtime/proc.c:1651 fp=0x1246aff4 sp=0x1246aff0
        created by runtime.init·4
            c:/go/src/runtime/proc.go:87 +0x25
        
        goroutine 3 [runnable]:
        runtime.bgsweep()
            c:/go/src/runtime/mgc0.go:66 fp=0x1246cff0 sp=0x1246cfec
        runtime.goexit()
            c:/go/src/runtime/proc.c:1651 fp=0x1246cff4 sp=0x1246cff0
        created by gc
            c:/go/src/runtime/mgc0.c:1382
FAIL
FAIL    runtime 37.175s
@rsc
Copy link
Contributor Author

rsc commented Oct 29, 2014

Comment 1:

I can't reproduce a binary at that CL while cross-compiling that tells me what
0x933d00+0x16a4 is.
However, the offset +0x4c is strongly indicative that 0x933d00+0x16a4 is allp[0]; +0x4c
is the offset of P's runq[0]. If you believe that starting point, the offending pointer
is allp[0].runq.defer.fn.
This looks very much like it was fixed by https://golang.org/cl/158750043 / hg
3014f5ee3005.

Status changed to Fixed.

@rsc
Copy link
Contributor Author

rsc commented Oct 29, 2014

Comment 2:

Issue #8911 has been merged into this issue.

@alexbrainman
Copy link
Member

Comment 3:

See go.exe and "go tool nm -n go.exe" output as at c5ee3f481631 attached. I don't see
why you cannot build it yourself. I can build it with no problem on linux/386.
Alex

Attachments:

  1. go.exe.gz (2564438 bytes)
  2. symbols.txt (402516 bytes)

@rsc
Copy link
Contributor Author

rsc commented Oct 29, 2014

Comment 4:

Thanks. My guess about allp[0] was wrong but the conclusion was correct.
In fact 933d00+0x16a4 seems to be m0.p, which amounts to the same thing.
For what it's worth, when I cross compiled from Mac I got a binary with bss starting
about 0x300000 earlier.
Even your binary's bss does not match the one on the builder (yours is 0x934d00 but the
builder ix 0x933d00), but it's close enough to tell what's going on.

@rsc rsc added fixed labels Oct 29, 2014
@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.4
Development

No branches or pull requests
3 participants
@rsc @gopherbot @alexbrainman