runtime/race: atomic operations fail on non-heap addresess #9136
Labels
Milestone
Comments
|
Comment 1 by szamcsi@google.com: I also have a simple program that fails with -race:
$ cat x.go
package main
import "fmt"
func main() {
a := []string{"a"}
i := 0
a[i], a[len(a)-1], a = a[len(a)-1], "", a[:len(a)-1]
fmt.Println(a)
}
$ go run x.go
panic: runtime error: index out of range
...
|
Moved this to https://golang.org/issue/9137 Thanks for the report! |
CL https://golang.org/cl/179030043 mentions this issue. |
|
This issue was closed by revision 2b3f379. Status changed to Fixed. |
rsc
added a commit
that referenced
this issue
May 11, 2015
…resses ««« CL 179030043 / e4ab8f908aac runtime: fix atomic operations on non-heap addresses Race detector runtime does not tolerate operations on addresses that was not previously declared with __tsan_map_shadow (namely, data, bss and heap). The corresponding address checks for atomic operations were removed in https://golang.org/cl/111310044 Restore these checks. It's tricker than just not calling into race runtime, because it is the race runtime that makes the atomic operations themselves (if we do not call into race runtime we skip the atomic operation itself as well). So instead we call __tsan_go_ignore_sync_start/end around the atomic operation. This forces race runtime to skip all other processing except than doing the atomic operation itself. Fixes #9136. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/179030043 »»» TBR=dvyukov CC=golang-codereviews https://golang.org/cl/180030043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 25, 2018
…resses ««« CL 179030043 / e4ab8f908aac runtime: fix atomic operations on non-heap addresses Race detector runtime does not tolerate operations on addresses that was not previously declared with __tsan_map_shadow (namely, data, bss and heap). The corresponding address checks for atomic operations were removed in https://golang.org/cl/111310044 Restore these checks. It's tricker than just not calling into race runtime, because it is the race runtime that makes the atomic operations themselves (if we do not call into race runtime we skip the atomic operation itself as well). So instead we call __tsan_go_ignore_sync_start/end around the atomic operation. This forces race runtime to skip all other processing except than doing the atomic operation itself. Fixes golang#9136. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/179030043 »»» TBR=dvyukov CC=golang-codereviews https://golang.org/cl/180030043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 26, 2018
…resses ««« CL 179030043 / e4ab8f908aac runtime: fix atomic operations on non-heap addresses Race detector runtime does not tolerate operations on addresses that was not previously declared with __tsan_map_shadow (namely, data, bss and heap). The corresponding address checks for atomic operations were removed in https://golang.org/cl/111310044 Restore these checks. It's tricker than just not calling into race runtime, because it is the race runtime that makes the atomic operations themselves (if we do not call into race runtime we skip the atomic operation itself as well). So instead we call __tsan_go_ignore_sync_start/end around the atomic operation. This forces race runtime to skip all other processing except than doing the atomic operation itself. Fixes golang#9136. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/179030043 »»» TBR=dvyukov CC=golang-codereviews https://golang.org/cl/180030043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 9, 2018
…resses ««« CL 179030043 / e4ab8f908aac runtime: fix atomic operations on non-heap addresses Race detector runtime does not tolerate operations on addresses that was not previously declared with __tsan_map_shadow (namely, data, bss and heap). The corresponding address checks for atomic operations were removed in https://golang.org/cl/111310044 Restore these checks. It's tricker than just not calling into race runtime, because it is the race runtime that makes the atomic operations themselves (if we do not call into race runtime we skip the atomic operation itself as well). So instead we call __tsan_go_ignore_sync_start/end around the atomic operation. This forces race runtime to skip all other processing except than doing the atomic operation itself. Fixes golang#9136. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/179030043 »»» TBR=dvyukov CC=golang-codereviews https://golang.org/cl/180030043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 20, 2018
…resses ««« CL 179030043 / e4ab8f908aac runtime: fix atomic operations on non-heap addresses Race detector runtime does not tolerate operations on addresses that was not previously declared with __tsan_map_shadow (namely, data, bss and heap). The corresponding address checks for atomic operations were removed in https://golang.org/cl/111310044 Restore these checks. It's tricker than just not calling into race runtime, because it is the race runtime that makes the atomic operations themselves (if we do not call into race runtime we skip the atomic operation itself as well). So instead we call __tsan_go_ignore_sync_start/end around the atomic operation. This forces race runtime to skip all other processing except than doing the atomic operation itself. Fixes golang#9136. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/179030043 »»» TBR=dvyukov CC=golang-codereviews https://golang.org/cl/180030043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 30, 2018
…resses ««« CL 179030043 / e4ab8f908aac runtime: fix atomic operations on non-heap addresses Race detector runtime does not tolerate operations on addresses that was not previously declared with __tsan_map_shadow (namely, data, bss and heap). The corresponding address checks for atomic operations were removed in https://golang.org/cl/111310044 Restore these checks. It's tricker than just not calling into race runtime, because it is the race runtime that makes the atomic operations themselves (if we do not call into race runtime we skip the atomic operation itself as well). So instead we call __tsan_go_ignore_sync_start/end around the atomic operation. This forces race runtime to skip all other processing except than doing the atomic operation itself. Fixes golang#9136. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/179030043 »»» TBR=dvyukov CC=golang-codereviews https://golang.org/cl/180030043
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
g% cat ~/x.go package main import ( "log" "sync/atomic" "syscall" "unsafe" ) func main() { data, err := syscall.Mmap(-1, 0, 4096, syscall.PROT_READ|syscall.PROT_WRITE, syscall.MAP_ANON) if err != nil { log.Fatal(err) } println(data) atomic.AddUint32((*uint32)(unsafe.Pointer(&data[0])), 1) } g% go run ~/x.go [4096/4096]0x2208335000 g% go run -race ~/x.go [4096/4096]0xbf2000 unexpected fault address 0x200002fc8000 fatal error: fault [signal 0xb code=0x1 addr=0x200002fc8000 pc=0xcc623] goroutine 1 [running]: runtime.gothrow(0x0, 0x0) /Users/rsc/g/go/src/runtime/panic.go:503 +0x8e fp=0x7fff5fbff4e0 sp=0x7fff5fbff4c8 exit status 2 g% Program should run under -race the same as it does normally. This worked in Go 1.3, because Go 1.3 implemented these using raceread/raceacquire instead of "fast paths". This is blocking Go 1.4. One possible fix is to restore the old "slow path" Go 1.3 implementations of these functions.The text was updated successfully, but these errors were encountered: