Skip to content
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.

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

runtime: fatal error: bad pointer in write barrier on linux-s390x-ibm #15270

Closed
mikioh opened this issue Apr 13, 2016 · 4 comments
Closed

runtime: fatal error: bad pointer in write barrier on linux-s390x-ibm #15270

mikioh opened this issue Apr 13, 2016 · 4 comments
Milestone

Comments

@mikioh
Copy link
Contributor

mikioh commented Apr 13, 2016

See http://build.golang.org/log/0c4bb957f324e4371f4364878cc79d42c57187b5

ok      regexp  0.074s
ok      regexp/syntax   0.388s
runtime: writebarrierptr *0x3503d0 = 0x400
fatal error: bad pointer in write barrier

runtime stack:
runtime.throw(0x26eb38, 0x1c)
    /data/golang/workdir/go/src/runtime/panic.go:566 +0x96 fp=0x3ff8dc7eee0 sp=0x3ff8dc7eec8
runtime.writebarrierptr.func1()
    /data/golang/workdir/go/src/runtime/mbarrier.go:140 +0xc0 fp=0x3ff8dc7ef08 sp=0x3ff8dc7eee0
runtime.systemstack(0xc82001a000)
    /data/golang/workdir/go/src/runtime/asm_s390x.s:249 +0x9a fp=0x3ff8dc7ef10 sp=0x3ff8dc7ef08
runtime.mstart()
    /data/golang/workdir/go/src/runtime/proc.go:1077 fp=0x3ff8dc7ef10 sp=0x3ff8dc7ef10
(snip)

/CC @aclements

@mikioh mikioh added this to the Go1.7 milestone Apr 13, 2016
@bradfitz
Copy link
Contributor

/cc @mundaym

@aclements
Copy link
Member

It looks like atomic.Storep1 on s390 generates a write barrier. On other platforms it does not (that's what runtime.atomicstorep is for, though this appears to be completely undocumented).

Going a little further down, here's where the "bad pointer write" actually happened:

goroutine 102586 [running]:
runtime.systemstack_switch()
    /data/golang/workdir/go/src/runtime/asm_s390x.s:203 +0x10 fp=0xc820409be8 sp=0xc820409be0
runtime.writebarrierptr(0x3503d0, 0x400)
    /data/golang/workdir/go/src/runtime/mbarrier.go:141 +0xd2 fp=0xc820409c18 sp=0xc820409be8
runtime/internal/atomic.Storep1(0x3503d0, 0x400)
    /data/golang/workdir/go/src/runtime/internal/atomic/atomic_s390x.go:43 +0x56 fp=0xc820409c30 sp=0xc820409c18
runtime.mapzero(0x206f80)
    /data/golang/workdir/go/src/runtime/hashmap.go:1079 +0x13a fp=0xc820409c60 sp=0xc820409c30
...

This is actually a scalar write (the zerosize global), but we're doing it using an atomic pointer write (yuck!).

I'll send a CL.

@gopherbot
Copy link

CL https://golang.org/cl/21993 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/21994 mentions this issue.

gopherbot pushed a commit that referenced this issue Apr 13, 2016
Make it clear that the point of this function stores a pointer
*without* a write barrier.

sed -i -e 's/Storep1/StorepNoWB/' $(git grep -l Storep1)

Updates #15270.

Change-Id: Ifad7e17815e51a738070655fe3b178afdadaecf6
Reviewed-on: https://go-review.googlesource.com/21994
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
@golang golang locked and limited conversation to collaborators Apr 13, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants