My go code errors out with a strack trace like this:
unexpected fault address 0x0
fatal error: fault
[signal 0xb code=0x80 addr=0x0 pc=0x407d50]
goroutine 52246872 [running]:
runtime.throw(0xad6a77)
/usr/local/go/src/pkg/runtime/panic.c:464 +0x69 fp=0xc214d2c1f8
runtime.sigpanic()
/usr/local/go/src/pkg/runtime/os_linux.c:237 +0xe9 fp=0xc214d2c210
hash_lookup(0x671ec0, 0xc21001eed0, 0xc214d2c2d0)
/usr/local/go/src/pkg/runtime/hashmap.c:502 +0x150 fp=0xc214d2c290
runtime.mapaccess(0x671ec0, 0xc21001eed0, 0xc214d2c318, 0xc214d2c328, 0xc214d2c330)
/usr/local/go/src/pkg/runtime/hashmap.c:1004 +0x57 fp=0xc214d2c2c0
runtime.mapaccess2(0x671ec0, 0xc21001eed0, 0x389c, 0x2060009ae, 0xad4dc0, ...)
/usr/local/go/src/pkg/runtime/hashmap.c:1061 +0x5d fp=0xc214d2c308
growmobile.com/rtb/cache.HistogramCheck(0xc2121eafd0, 0xc, 0xeca93c6a0, 0x852a9f8, 0xad4dc0, ...)
/mnt/rtb_server/go/src/growmobile.com/rtb/cache/histogram_cache.go:211 +0x16b fp=0xc214d2c798
growmobile.com/rtb/controller.processBidRequest(0xc2121eafd0, 0xc, 0xeca93c6a0, 0x852a9f8, 0xad4dc0, ...)
/mnt/rtb_server/go/src/growmobile.com/rtb/controller/bidder_logic.go:272 +0x7c2 fp=0xc214d2e928
----- stack segment boundary -----
growmobile.com/rtb/controller.Bid(0x7f7a14250ed8, 0xc2197b3a00, 0xc2157f9dd0)
/mnt/rtb_server/go/src/growmobile.com/rtb/controller/controller.go:96 +0x903 fp=0x7f79f8dd9da0
net/http.HandlerFunc.ServeHTTP(0x800850, 0x7f7a14250ed8, 0xc2197b3a00, 0xc2157f9dd0)
/usr/local/go/src/pkg/net/http/server.go:1220 +0x40 fp=0x7f79f8dd9dc0
net/http.(*ServeMux).ServeHTTP(0xc21001e660, 0x7f7a14250ed8, 0xc2197b3a00, 0xc2157f9dd0)
/usr/local/go/src/pkg/net/http/server.go:1496 +0x163 fp=0x7f79f8dd9df8
net/http.serverHandler.ServeHTTP(0xc21001fa00, 0x7f7a14250ed8, 0xc2197b3a00, 0xc2157f9dd0)
/usr/local/go/src/pkg/net/http/server.go:1597 +0x16e fp=0x7f79f8dd9e38
net/http.(*conn).serve(0xc215d60a00)
/usr/local/go/src/pkg/net/http/server.go:1167 +0x7b7 fp=0x7f79f8dd9f98
runtime.goexit()
/usr/local/go/src/pkg/runtime/proc.c:1394 fp=0x7f79f8dd9fa0
created by net/http.(*Server).Serve
/usr/local/go/src/pkg/net/http/server.go:1644 +0x28b
goroutine 1 [chan receive]:
main.serve()
/mnt/rtb_server/go/src/growmobile.com/rtb/rtb_server/rtb_server.go:71 +0x5f0
main.main()
/mnt/rtb_server/go/src/growmobile.com/rtb/rtb_server/rtb_server.go:86 +0x1d8
At the time it is trying to access a hash which is a struct that maps to a pointer. The hash is a global one and looks like this:
var histogramCache = make(map[model.HistogramKey]*model.HistogramValue)
The access is a very standard access which looks like:
value, ok := histogramCache[key]
I tried to google something similar but could not find it. I do not use cgo or assertions.
This is the go version we are using: go version go1.2 linux/amd64
Thank you, any help would be appreciated.
Maps are not safe for concurrent access. This might very well be the reason why your code is failing.
Use a central goroutine (see this example) and retrieve things using channels or use locking tools from sync.
Reinstalling the goland package fixed this problem for me. Some dependencies had been replaced by another package or were not correctly installed.
Related
cmd.StdoutPipe example at go documentation: https://pkg.go.dev/os/exec#example-Cmd.StdoutPipe does not run in playground.
https://play.golang.org/p/ek7-_Xa_bN3
Error:
fatal error: all goroutines are asleep - deadlock!
goroutine 1 [IO wait]:
internal/poll.runtime_pollWait(0x7faec2ac4e88, 0x72)
/usr/local/go-faketime/src/runtime/netpoll.go:234 +0x89
internal/poll.(*pollDesc).wait(0xc000074180, 0xc000100000, 0x1)
/usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:84 +0x32
internal/poll.(*pollDesc).waitRead(...)
/usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:89
internal/poll.(*FD).Read(0xc000074180, {0xc000100000, 0x200, 0x200})
/usr/local/go-faketime/src/internal/poll/fd_unix.go:167 +0x25a
os.(*File).read(...)
/usr/local/go-faketime/src/os/file_posix.go:32
os.(*File).Read(0xc00000e028, {0xc000100000, 0x28, 0xc000060e80})
/usr/local/go-faketime/src/os/file.go:119 +0x5e
encoding/json.(*Decoder).refill(0xc00007e000)
/usr/local/go-faketime/src/encoding/json/stream.go:165 +0x17f
encoding/json.(*Decoder).readValue(0xc00007e000)
/usr/local/go-faketime/src/encoding/json/stream.go:140 +0xbb
encoding/json.(*Decoder).Decode(0xc00007e000, {0x4cf580, 0xc00000c048})
/usr/local/go-faketime/src/encoding/json/stream.go:63 +0x78
main.main()
/tmp/sandbox2294589397/prog.go:24 +0x185
Program exited.
Locally it's running correctly, no deadlock. I am not able to understand why deadlock happens in go playground.
From the documentation on the os.exec package (which is where this example comes from):
Note that the examples in this package assume a Unix system. They may
not run on Windows, and they do not run in the Go Playground used by
golang.org and godoc.org.
That note doesn't provide a reason, but the reason is presumably that allowing user-provided unix commands to run would give a broader attack surface for malicious code. It's not that it's impossible to allow this in a relatively secure way, but there's various tradeoffs which make disallowing os.exec a natural choice.
I am trying to build CockroachDB from sources on a RPi 3, following a couple of posts (this and this).
My RaspberryPi setup:
OS: 2018-06-27-raspbian-stretch
CPU: ARMv7 rev 4(v71)
Mem: 1G + SWAP: 1.5G
Go version: go1.11 linux/arm
I fixed a couple of errors regarding 3rd party libraries while 'make'ing it but now I got stuck on this:
pi#raspberrypi:~/work/go/src/github.com/cockroachdb/cockroach $ make build TAGS='stdmalloc' -j2
GOPATH set to /home/pi/work/go
go build -o cockroach -v -tags 'stdmalloc make arm_linux_gnueabihf_stdmalloc' -ldflags '-X github.com/cockroachdb/cockroach/pkg/build.typ=development -extldflags "" -X "github.com/cockroachdb/cockroach/pkg/build.tag=v2.2.0-alpha.00000000-668-gf76d921f42-dirty" -X "github.com/cockroachdb/cockroach/pkg/build.rev=f76d921f4262356fde83312d0f471262d995f1e0" -X "github.com/cockroachdb/cockroach/pkg/build.cgoTargetTriple=arm-linux-gnueabihf" -X "github.com/cockroachdb/cockroach/pkg/build.utcTime=2018/09/11 12:47:32"' ./pkg/cmd/cockroach
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x2372b8]
goroutine 1 [running]:
runtime/internal/atomic.goLoad64(0x3d65bdc, 0x0, 0x5607a20)
/usr/local/go/src/runtime/internal/atomic/atomic_arm.go:124 +0x1c
github.com/cockroachdb/cockroach/pkg/util/humanizeutil.(*BytesValue).String(0x55fb578, 0x5607a01, 0x56d9ea0)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/util/humanizeutil/humanize.go:109 +0x28
github.com/cockroachdb/cockroach/pkg/cli.(*bytesOrPercentageValue).String(0x57b4920, 0x56d9ea0, 0x7)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags_util.go:492 +0x20
github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag.(*FlagSet).VarPF(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x56d2900, 0x169, 0x56d9ea0)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag/flag.go:778 +0x24
github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag.(*FlagSet).VarP(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x56d2900, 0x169)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag/flag.go:786 +0x5c
github.com/cockroachdb/cockroach/pkg/cli.VarFlag(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x0, 0x0, 0x1fa4462, ...)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags.go:129 +0x6c
github.com/cockroachdb/cockroach/pkg/cli.init.5()
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags.go:324 +0x6c0
Makefile:1288: recipe for target 'docs/generated/settings/settings.html' failed
make: *** [docs/generated/settings/settings.html] Error 2
make: *** Deleting file 'docs/generated/settings/settings.html'
Any ideas what might be wrong?
thanks for the question. I was the original author of that blog post. It looks like you're running into an issue related to https://github.com/golang/go/issues/9959. It looks like golang requires 64-bit alignment of 64-bit words when atomically accessed. This is somewhat tricky to enforce across an entire project. Still, we can try to get this working by removing the atomic access on pkg/util/humanizeutil/humanize.go:109 (which doesn't look necessary) and replacing it with return IBytes(*b.val). That should at least get you past this roadblock. There may be other issues you run into after this though. Unfortunately, CockroachDB has never set up CI around a 32-bit ARMv7 build because 32-bit architectures have never been officially supported by the project.
However, a 64-bit ARMv8 build is more actively maintained. In fact, an entire cross-compilation toolchain has been introduced to build CockroachDB for ARMv8 on an x86_64 host. Compilation using this toolchain can be kicked off by running build/builder.sh mkrelease arm64-linux-gnueabi. The resulting binary can be dropped onto a RaspberryPi running a 64-bit OS like https://wiki.debian.org/RaspberryPi3. I actually tried this out last week and ran into no problems.
I vendored two projects in my go project. And I successfully compiled my project. When I ran my project, it reported error "panic: http: multiple registrations for /debug/requests". The detailed errors is shown below.
goroutine 1 [running]:
net/http.(*ServeMux).Handle(0x19ae000, 0x126bb20, 0xf, 0x1964540, 0x1297d90)
/usr/local/go/src/net/http/server.go:2270 +0x627
net/http.(*ServeMux).HandleFunc(0x19ae000, 0x126bb20, 0xf, 0x1297d90)
/usr/local/go/src/net/http/server.go:2302 +0x55
net/http.HandleFunc(0x126bb20, 0xf, 0x1297d90)
/usr/local/go/src/net/http/server.go:2314 +0x4b
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/vendor/golang.org/x/net/trace.init.0()
/home/chalex/ibm/src/github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/vendor/golang.org/x/net/trace/trace.go:115 +0x42
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/vendor/golang.org/x/net/trace.init()
<autogenerated>:1 +0x1cd
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/vendor/google.golang.org/grpc.init()
<autogenerated>:1 +0x82
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/third_party/github.com/hyperledger/fabric/protos/peer.init()
<autogenerated>:1 +0x6f
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/api/apitxn.init()
<autogenerated>:1 +0x44
github.own.com/chalex/testfabric/chaincode/client.init()
<autogenerated>:1 +0x49
main.init()
Does anyone have any idea on how to fix it? I guess it's because the two projects I imported both listen on /debug/requests?
I found the reason. It's because of the golang.org/x/net/trace project. In it's init() function, they handle the debug/request with hard code. So if two projects both import that library, then there is a conflict.
More than one project used golang.org/x/net/trace, and some project saved golang.org/x/net/trace in its vendor directory, so that is causing the conflict. Fix the conflict by deleting others and only leaving one,then the problem will be solved.
I try to reproduce race condition in my app, but go build -race doesnt show any error, even on virtual machine with Linux onboard.
Machine:
Windows: 4 cores
Linux: 2 cores (Ubuntu Xenial x64 via Vagrant and VirtualBox)
go version:
Linux: go version go1.8.3 linux/amd64
Windows: go version go1.8.3 windows/amd64
go env:
Linux: https://pastebin.com/pXURKfj3
Windows: https://pastebin.com/MTdjNnVW
Example 1: https://play.golang.org/p/x-eD6bBrzz
Example 2: https://play.golang.org/p/FSg8P7UP8p
Is my examples has data race? Both of them no according to build with go build -race
If examples above hasnt data race condition, could somebody please send me example where i can see a real data race in Golang, so i can test the -race flag? I also found some examples on the web, some of them doesnt compiling, some of them same shows that there is no data race.
Thank you!
Both of your examples has data race issue. You can find out data race in following ways.
go run -race program.go
go test -race <package-name> or go test -race -run=<testcase-func-name>
go build -race program.go then execute the program
go install -race <package-name> then execute the program
Example 1: data race info
$ go build -race datarace-try1.go
$ ./datarace-try1
8
==================
WARNING: DATA RACE
Read at 0x00c4200761a8 by goroutine 7:
main.main.func1()
/Users/jeeva/go_playground/datarace-try1.go:23 +0x74
Previous write at 0x00c4200761a8 by goroutine 6:
main.main.func1()
/Users/jeeva/go_playground/datarace-try1.go:23 +0x8d
Goroutine 7 (running) created at:
main.main()
/Users/jeeva/go_playground/datarace-try1.go:25 +0xee
Goroutine 6 (running) created at:
main.main()
/Users/jeeva/go_playground/datarace-try1.go:25 +0xee
==================
187410
Found 1 data race(s)
Example 2: data race info
$ go build -race datarace-try2.go
$ ./datarace-try2
==================
WARNING: DATA RACE
Read at 0x00c420078178 by main goroutine:
main.main()
/Users/jeeva/go_playground/datarace-try2.go:10 +0x12e
Previous write at 0x00c420078178 by goroutine 6:
main.main.func1()
/Users/jeeva/go_playground/datarace-try2.go:15 +0xd4
Goroutine 6 (finished) created at:
main.main()
/Users/jeeva/go_playground/datarace-try2.go:17 +0xf1
==================
==================
WARNING: DATA RACE
Read at 0x00c420078178 by goroutine 7:
main.main.func2()
/Users/jeeva/go_playground/datarace-try2.go:20 +0x3f
Previous write at 0x00c420078178 by goroutine 6:
main.main.func1()
/Users/jeeva/go_playground/datarace-try2.go:15 +0xd4
Goroutine 7 (running) created at:
main.main()
/Users/jeeva/go_playground/datarace-try2.go:23 +0x11d
Goroutine 6 (finished) created at:
main.main()
/Users/jeeva/go_playground/datarace-try2.go:17 +0xf1
==================
finish
Found 2 data race(s)
exit status 66
So I'm receiving a fault when running go test --race my/package/ya. The output looks like this:
unexpected fault address 0x200015a490e0
fatal error: fault
[signal 0xb code=0x1 addr=0x200015a490e0 pc=0x47399ac]
goroutine 1 [running, locked to thread]:
runtime.throw(0x0, 0xc820000180)
/opt/go1.6/src/runtime/panic.go:530 +0x90 fp=0x7fff5fbfeb80 sp=0x7fff5fbfeb68
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/opt/go1.6/src/runtime/asm_amd64.s:1998 +0x1
I've tried catching this fault in a TestMain, but apparently my TestMain doesn't get called. I've tried using -trace to generate a trace file, but the file never is written although the testing file pkg.out is written. I'm not entirely sure where to go from here since the output doesn't really provide many hints. I suppose I can attempt gdb and delve, but haven't had luck with either of those in the past.
I'm wondering if there is something else to consider?
Additional notes: this fault only occurs when the --race flag is present. Go 1.6 darwin/amd64.
(Warming up this really old question)
Simply upgrade to Go 1.20 (see issue on GitHub).
For reference, the errors are (taken from issue):
In version 1.19:
syscall.ptrace: nosplit stack over 792 byte limit
syscall.ptrace<1>
grows 128 bytes, calls syscall.ptrace1<1>
[...]
In version 1.18.5
runtime.fatalthrow: nosplit stack overflow
792 assumed on entry to syscall.ptrace<1> (nosplit)
[...]