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.
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 use this on Ubuntu 20.04 and Raspberry Pi OS 5.10 but this is not a Linux related issue.
I'm having an issue with a Go program called Bettercap 2 ( https://www.bettercap.org/ and the repository: https://github.com/bettercap/bettercap ) when I use its function to scan bluetooth devices "ble.recon on" with a different bluetooth dongle.
When I use it with a dongle using Realtek RTL8761b drivers ( MPOW MPBH456AB ) you can find on amazon it works well, but when I use a NordicSemi nrf52840 dongle ( https://www.nordicsemi.com/Products/Development-hardware/nrf52840-dongle ) which is my goal, flashed with Zephyr RTOS' hci_usb sample ( https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_usb ) which is supposed to turn any micro controller using bluetooth into a regular bluetooth dongle that any computer is supposed to recognize as, it throws this error:
>> ble.recon on
panic: runtime error: slice bounds out of range [:1] with capacity 0
goroutine 1 [running]:
github.com/bettercap/gatt/linux/cmd.(*Cmd).SendAndCheckResp(0x1c637c0, 0xa0c760, 0x1c64fe8, 0x1c6501c, 0x1, 0x1, 0x0, 0x0)
/home/pi/go/pkg/mod/github.com/bettercap/gatt#v0.0.0-20210514133428-df6e615f2f67/linux/cmd/cmd.go:98 +0x1b4
github.com/bettercap/gatt/linux.(*HCI).resetDevice(0x18ac0a0, 0x93dc10, 0x18ac0a0)
/home/pi/go/pkg/mod/github.com/bettercap/gatt#v0.0.0-20210514133428-df6e615f2f67/linux/hci.go:273 +0x2f0
github.com/bettercap/gatt/linux.NewHCI(0xffffffff, 0x184fd01, 0xff, 0x2, 0x0, 0x0)
/home/pi/go/pkg/mod/github.com/bettercap/gatt#v0.0.0-20210514133428-df6e615f2f67/linux/hci.go:90 +0x4c0
github.com/bettercap/gatt.NewDevice(0x184fd1c, 0x2, 0x2, 0x3c, 0x184fd24, 0x1, 0x1)
/home/pi/go/pkg/mod/github.com/bettercap/gatt#v0.0.0-20210514133428-df6e615f2f67/device_linux.go:57 +0x114
github.com/bettercap/bettercap/modules/ble.(*BLERecon).Configure(0x18a2780, 0x0, 0x4)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/modules/ble/ble_recon.go:165 +0x1cc
github.com/bettercap/bettercap/modules/ble.(*BLERecon).Start(0x18a2780, 0x1, 0x1b2c001)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/modules/ble/ble_recon.go:183 +0x1c
github.com/bettercap/bettercap/modules/ble.NewBLERecon.func1(0x0, 0x0, 0x0, 0x84f358, 0xc)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/modules/ble/ble_recon.go:56 +0x1c
github.com/bettercap/bettercap/session.(*ModuleHandler).Exec(0x1b2c0c0, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/session/module_handler.go:74 +0x80
github.com/bettercap/bettercap/session.(*Session).Run(0x18fb2c0, 0x1c64e30, 0xc, 0x1, 0x1)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/session/session.go:416 +0x284
main.main()
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/main.go:94 +0x8c8
I have no idea what it means as I'm not a Go developer and have never used this language, I've looked at the error and it seems to be in the code but not knowing Go, I prefer to ask before I modify anything.
The problem is only when I'm using the nrf dongle, otherwise it works with the host's bluetooth and the other realtek dongle.
The nrf dongle works with the BlueZ stack, here are the results:
bluetoothctl ( has a BD address )
Scan does work
$ sudo bluetoothctl
Agent registered
[bluetooth]# list
Controller EB:XX:XX:XX:XX:XX BlueZ 5.50 [default]
btmgmt ( finds the controller )
Scan does work
$ sudo btmgmt --index 0
[hci0]# auto-power
Found controller with index 0
[hci0]# find -l
But, although deprecated, hciconfig and hcitool recognize the realtek dongle but for this one, here are the results:
hciconfig ( no BD address )
$ hciconfig
hci0: Type: Primary Bus: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 27:7 SCO MTU: 0:0
UP RUNNING
RX bytes:1593 acl:0 sco:0 events:88 errors:0
TX bytes:285 acl:0 sco:0 commands:51 errors:0
hcitool ( Doesn't find the controller )
$ hcitool scan
Scanning ...
Inquiry failed: Operation not supported
So, I assume the dongle works well with BlueZ, being the Linux official bluetooth stack it's a good sign, but I thought that Bettercap was also using BlueZ and in that sense the dongle should work.
I don't think there are any drivers to install for the dongle as of the fact that when it is flashed ( J-Link ) it turns into a generic bluetooth dongle.
Do you have any idea what the problem could be ?
I believe the error is coming from https://github.com/bettercap/gatt/blob/master/linux/cmd/cmd.go#L98
The program is attempting to write something to the device and expects that it will receive a response as long as there was no error sending. But apparently the Send call is successful but receives an empty response.
I'd suggest opening an issue over there and asking your question.
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)
[...]
I'm running wercker.com on Mac OS. Once in a while wercker crashes with the following error message although the container keeps running:
PANIC dial tcp 192.168.99.100:2376: socket: too many open files
panic: (*logrus.Entry) (0x6bfa60,0xc8202ceb00)
goroutine 2101 [running]:
github.com/wercker/wercker/vendor/github.com/Sirupsen/logrus.(*Entry).log(0xc8202ceb00, 0x0, 0xc8203d87c0, 0x39)
/gopath/src/github.com/wercker/wercker/vendor/github.com/Sirupsen/logrus/entry.go:103 +0x5fb
github.com/wercker/wercker/vendor/github.com/Sirupsen/logrus.(*Entry).Panic(0xc8202ceb00, 0xc8203ebd30, 0x1, 0x1)
/gopath/src/github.com/wercker/wercker/vendor/github.com/Sirupsen/logrus/entry.go:148 +0x7c
github.com/wercker/wercker/docker.(*WatchStep).Execute.func5(0xc82037ba40, 0xc8202ceb40, 0xc820178640, 0xc82005cd60, 0xc820165800, 0x40, 0xc8203b5860, 0xc82010bce0, 0xc82037b8c0)
/gopath/src/github.com/wercker/wercker/docker/watchstep.go:297 +0x723
created by github.com/wercker/wercker/docker.(*WatchStep).Execute
/gopath/src/github.com/wercker/wercker/docker/watchstep.go:312 +0x91d
...
I'm running a Typescript Node.js app inside the container which is being restarted often via wercker's "internal/watch". Typescript is being compiled to JS outside of the container by the IDE, but all the files are shared with the container.
What is the best way to avoid this issue?
After setting the local file limits up, it's working.
See: Is there a fix for the “Too many open files in system” error on OS X 10.7.1.
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.