-
Notifications
You must be signed in to change notification settings - Fork 543
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
gorocksdb core dump on Raspberry Pi 4's BCM2711 processor #137
Comments
As I don't have access to any Raspberry Pi 4, I can't try to reproduce the reported issue on Raspberry Pi 4. Dragonboat works fine on ARM64, there is a travis-ci target running all tests on ARM64 for each push using pebble as the storage engine. I've also added travis-ci targets to use RocksDB on ARM64 to run all LogDB tests. As you can see from the links below, there is no ARM64 specific issue running Go1.14 + ARM64 + RocksDB with CGO. https://travis-ci.com/github/lni/dragonboat/builds/179036653 The above tests were using Ubuntu 18.04 for ARM64, RocksDB version is 5.8 (default package in Ubuntu 18.04 installed via apt) and Go1.14 for ARM64. I don't know much about Raspberry Pi, but maybe you can try Ubuntu rather than Raspberian? |
Confirmed working on Ubuntu 64-bit (20.04.01 and 18.04) with go 1.14.7 on RPI 4 model B with RocksDB and CGO. Hopefully it's just an issue with the current beta release. You can try running Raspberian in a virtual machine if you're curious. I use QEMU on Linux with the kernels at https://github.com/dhruvvyas90/qemu-rpi-kernel. I believe VirtualBox will also work https://raspberrytips.com/run-raspberry-in-virtual-machine/. Would be great to have things working on the official OS for the PI. Thanks! |
Great to see it works on Raspberry Pi 4 + 64bit Ubuntu. |
Root cause follow-up: TL;DR use librocksdb-dev from OS package repository or github.com/rocksdb/tags/v5.17.2 when building from source. I wasn't aware of the librocksdb-dev package available in the package repo (thanks for the linked travis job!) so I compiled from rocksdb/master which doesn't appear to be compatible with gorocksdb tecbot/gorocksdb#185 Raspi OS 64bit and Ubuntu ARM64 20.04 both have librocksdb-dev v5.17.2-3 in their repos which work as expected. Once I checked out the v5.17.2 tag and recompiled on Raspi OS the write CGO call worked as expected. I was able to get as far as librocksdb-dev v6.3.6 on Raspi OS (gcc-8) after disabling errors for unused functions Ubuntu ARM64 comes with gcc-9 and does not compile librocksdb/tags/v5.17.2 out of the box. To get a successful build, use Also confirmed working with go1.15. |
Thanks for the extra info, it is very useful. Just a quick question - did you get any chance to try any more recent version of RocksDB (say 6.4.x or 6.5.x) on Ubuntu ARM64? I can confirm that 6.5.x works fine in my AMD64 systems. |
I did try, versions later than v6.3.6 results in the core dump on both Raspios and Ubuntu ARM64. My AMD64 desktop is able to compile and run the master branch. |
Thanks for the information. I will try Ubuntu ARM64 + the latest RocksDB release on AWS Graviton2 instances this coming weekend to see is there anything I can find. |
Interestingly, I didn't get any trouble building/running Dragonboat + RocksDB v6.11.4 on a m6g.xlarge instance (ARM64) from AWS. I used Ubuntu 20.04 ARM64, RocksDB v6.11.4 was built with the default g++-9.3 compiler with its default options. Go 1.15 was used to play with the HEAD of Dragonboat's master branch. Please see logs below. It seems to me that the problem you experienced is still tools/environment related.
|
I'll reserve some time this week to put together a docker container or packer image to reproduce the problem. Also happy to screen share with you. |
You may also want to try Ubuntu 20.04 and its default g++-9.3 with the latest RocksDB v6.11.4 to see whether they work on your Raspberry Pi 4. |
Here is what I get on my RPI 4 running Ubuntu 20.04.1 LTS ARM64.
Using the flags mentioned in an earlier post:
Dragonboat HEAD using librocksdb v6.3.6 and the example you provided:
Dragonboat HEAD using librocksdb v6.3.6 and the example you provided with additional CGO_LDFLAGS:
Dragonboat HEAD using librocksdb v6.11.4 and the example you provided:
Dragonboat HEAD using librocksdb v6.11.4 and the example you provided with additional CGO_LDFLAGS:
Dragonboat release-3.2 using lobrocksdb v6.11.4 and the example you provided:
Dragonboat release-3.2 using lobrocksdb v6.11.4 and the example you provided with additional CGO_LDFLAGS:
|
Let's first rule out hardware issue here, e.g. golang/go#28431 had similar illegal instruction error caused by some particular processors. For the above test-logdb.bin executable that generated the reported illegal instruction error, you can copy that executable to an ARM64 based AWS m6g instance running the same version of Ubuntu and run from there to see whether it works. You may also want to build that test-logdb.bin using RocksDB v6.11.4 on an AWS m6g instance (which has been confirmed to work fine) and copy it over to your Raspberry Pi4 to see whether it works. When RocksDB is used as a shared lib, make you the share lib is also copied over to the new platform. |
Another thing I noticed is that you are using RocksDB as a static lib, it shouldn't be a problem in theory but just saw similar illegal instruction errors reported by other Go users when statically linked binaries were used. https://groups.google.com/forum/#!topic/golang-nuts/1R4yayrgWUI Can you try building RocksDB as a shared lib as well? |
static_lib test results test-logdb.bin built with librocksdb-v6.11.4 on the RPI, run on the m6g instance:
Dragonboat HEAD with librocksdb-v6.11.4 on the m6g instance:
Dragonboat HEAD with librocksdb-v6.11.4 on the m6g instance with additional CGO_LDFLAGS:
Dragonboat HEAD built with librocksdb-v6.11.4 on the m6g instance with additional CGO_LDFLAGS, run on the RPI:
|
shared_lib test results Dragonboat HEAD with librocksdb-v6.11.4 built on m6g, run on m6g:
test-logdb.bin and librocksdb-v6.11.4 built on m6g, run on RPI:
Dragonboat HEAD and librocksdb-v6.11.4 built and run on RPI:
Dragonboat HEAD and librocksdb-v6.11.4 built on RPI, run on mg6:
|
As you can see from the above static_lib test results, the same test executable that works fine on m6g would cause illegal instruction error on Raspberry Pi4. It seems to me that there are some inconsistent behaviors between the ARM64 processors used on m6g and the one on Raspberry Pi4. I now have the feeling that the error should be reproducible using a minimum Go program (without any Dragonboat code) that uses gorocksdb to open a DB and write a record to it. If such a minimum program can be constructed to reproduce the error, please raise an issue with the Go project. Another quick check you may want to do is to see what actual instruction (pointed by the PC register) was considered illegal. That might provide extra info on what is going on. Based on what we have seen in the past couple of days, I think the issue is highly unlikely related to any Dragonboat code. |
facebook/rocksdb#7233 seems to be the fix for this issue. Not verified on my end as I don't have any Raspberry Pi hardware. |
Dragonboat version
3.2.2
Expected behavior
gorocksdb writes successfully
Actual behavior
goroutine 0 [idle]:
runtime: unknown pc 0xffb2ac
stack: frame={sp:0x7f9582bbb0, fp:0x0} stack=[0x7f9502c980,0x7f9582c580)
0000007f9582bab0: 0000007f9582bad0 0000007f9582bad0
0000007f9582bac0: 0000000000000000 0000000000000020
0000007f9582bad0: 0000000000000000 0000000000000000
0000007f9582bae0: 0000000000000000 0000000000000000
0000007f9582baf0: 0000000000000001 0000007f8c002797
0000007f9582bb00: 0000000000000005 0000007f9582bb38
0000007f9582bb10: 0000000000556394 <runtime.netpoll+444> 0000007f94ffdbc8
0000007f9582bb20: 0000000100000077 0000000000000000
0000007f9582bb30: 000000400016ea80 0000007f9582c3a8
0000007f9582bb40: 00000000005612e4 <runtime.findrunnable+1804> 0000007f9582bb90
0000007f9582bb50: 0000007f94ffdbc8 00000001000000e9
0000007f9582bb60: 0000000000000001 0000007f9582bb00
0000007f9582bb70: 0000007f00000001 0000000000000001
0000007f9582bb80: 0000000000000000 0000000000000000
0000007f9582bb90: 000000400016ea80 0000000000000000
0000007f9582bba0: 0000000000000000 0000000000000005
0000007f9582bbb0: <0000007f9582bc40 0000000000e7647c
0000007f9582bbc0: 0000007f9582be10 0000000000003c37
0000007f9582bbd0: 0000000000003c37 0000007f7436e740
0000007f9582bbe0: 0000007f8c006e90 0000000000000001
0000007f9582bbf0: 0000000000000007 0000000000000000
0000007f9582bc00: 0000000000000000 00013c3700000000
0000007f9582bc10: 0000000000000000 0000000000000000
0000007f9582bc20: 0000000000000000 0000000000000000
0000007f9582bc30: 0000000000000000 0000000000000000
0000007f9582bc40: 0000007f9582bd00 0000000000e36308
0000007f9582bc50: 0000007f74199e30 0000007f9582be10
0000007f9582bc60: 0000000000000000 00000000159117c0
0000007f9582bc70: 0000007f7419aad0 0000007f7436e740
0000007f9582bc80: 0000000000000001 0000000000000000
0000007f9582bc90: 0000000000000016 0000007f9582be10
0000007f9582bca0: 000000000148ed98 0000007f9582bce8
runtime: unknown pc 0xffb2ac
stack: frame={sp:0x7f9582bbb0, fp:0x0} stack=[0x7f9502c980,0x7f9582c580)
0000007f9582bab0: 0000007f9582bad0 0000007f9582bad0
0000007f9582bac0: 0000000000000000 0000000000000020
0000007f9582bad0: 0000000000000000 0000000000000000
0000007f9582bae0: 0000000000000000 0000000000000000
0000007f9582baf0: 0000000000000001 0000007f8c002797
0000007f9582bb00: 0000000000000005 0000007f9582bb38
0000007f9582bb10: 0000000000556394 <runtime.netpoll+444> 0000007f94ffdbc8
0000007f9582bb20: 0000000100000077 0000000000000000
0000007f9582bb30: 000000400016ea80 0000007f9582c3a8
0000007f9582bb40: 00000000005612e4 <runtime.findrunnable+1804> 0000007f9582bb90
0000007f9582bb50: 0000007f94ffdbc8 00000001000000e9
0000007f9582bb60: 0000000000000001 0000007f9582bb00
0000007f9582bb70: 0000007f00000001 0000000000000001
0000007f9582bb80: 0000000000000000 0000000000000000
0000007f9582bb90: 000000400016ea80 0000000000000000
0000007f9582bba0: 0000000000000000 0000000000000005
0000007f9582bbb0: <0000007f9582bc40 0000000000e7647c
0000007f9582bbc0: 0000007f9582be10 0000000000003c37
0000007f9582bbd0: 0000000000003c37 0000007f7436e740
0000007f9582bbe0: 0000007f8c006e90 0000000000000001
0000007f9582bbf0: 0000000000000007 0000000000000000
0000007f9582bc00: 0000000000000000 00013c3700000000
0000007f9582bc10: 0000000000000000 0000000000000000
0000007f9582bc20: 0000000000000000 0000000000000000
0000007f9582bc30: 0000000000000000 0000000000000000
0000007f9582bc40: 0000007f9582bd00 0000000000e36308
0000007f9582bc50: 0000007f74199e30 0000007f9582be10
0000007f9582bc60: 0000000000000000 00000000159117c0
0000007f9582bc70: 0000007f7419aad0 0000007f7436e740
0000007f9582bc80: 0000000000000001 0000000000000000
0000007f9582bc90: 0000000000000016 0000007f9582be10
0000007f9582bca0: 000000000148ed98 0000007f9582bce8
goroutine 4 [syscall]:
runtime.cgocall(0xdb4da0, 0x4045a54918, 0x40002083f8)
/usr/local/go/src/runtime/cgocall.go:133 +0x50 fp=0x4045a548e0 sp=0x4045a548a0 pc=0x52b7f8
github.com/lni/dragonboat/v3/internal/logdb/kv/rocksdb/gorocksdb._Cfunc_rocksdb_write(0x7f7436e480, 0x7f74229810, 0x159117c0, 0x40002083f8)
_cgo_gotypes.go:4066 +0x40 fp=0x4045a54910 sp=0x4045a548e0 pc=0xa2f088
github.com/lni/dragonboat/v3/internal/logdb/kv/rocksdb/gorocksdb.(*DB).Write.func1(0x400031cb60, 0x40002082b0, 0x40000bc348, 0x40002083f8)
/home/pi/go/pkg/mod/github.com/lni/dragonboat/[email protected]/internal/logdb/kv/rocksdb/gorocksdb/db.go:381 +0xf4 fp=0x4045a54960 sp=0x4045a54910 pc=0xa3b4ac
github.com/lni/dragonboat/v3/internal/logdb/kv/rocksdb/gorocksdb.(*DB).Write(0x400031cb60, 0x40002082b0, 0x40000bc348, 0x0, 0x0)
/home/pi/go/pkg/mod/github.com/lni/dragonboat/[email protected]/internal/logdb/kv/rocksdb/gorocksdb/db.go:381 +0x60 fp=0x4045a549c0 sp=0x4045a54960 pc=0xa32328
github.com/lni/dragonboat/v3/internal/logdb/kv/rocksdb.(*KV).CommitWriteBatch(0x4000184bc0, 0x1441a40, 0x40000bc348, 0x100, 0x1441a40)
/home/pi/go/pkg/mod/github.com/lni/dragonboat/[email protected]/internal/logdb/kv/rocksdb/kv_rocksdb.go:323 +0x54 fp=0x4045a54a00 sp=0x4045a549c0 pc=0xa4458c
github.com/lni/dragonboat/v3/internal/logdb.(*rdb).saveRaftState(0x4000200f00, 0x400025a000, 0x1, 0x100, 0x14478e0, 0x4000212100, 0x4045a55068, 0xa6b9e8)
/home/pi/go/pkg/mod/github.com/lni/dragonboat/[email protected]/internal/logdb/rdb.go:206 +0x1ec fp=0x4045a55020 sp=0x4045a54a00 pc=0xa4bef4
github.com/lni/dragonboat/v3/internal/logdb.(*ShardedRDB).SaveRaftState(0x40002d6190, 0x400025a000, 0x1, 0x100, 0x14478e0, 0x4000212100, 0x1, 0x40530ac000)
/home/pi/go/pkg/mod/github.com/lni/dragonboat/[email protected]/internal/logdb/sharded_rdb.go:159 +0x90 fp=0x4045a55070 sp=0x4045a55020 pc=0xa500d8
github.com/lni/dragonboat/v3.(*execEngine).execNodes(0x4000116090, 0x8, 0x400054a240, 0x4045a3b050, 0x400018b860)
/home/pi/go/pkg/mod/github.com/lni/dragonboat/[email protected]/execengine.go:899 +0x53c fp=0x4045a55d90 sp=0x4045a55070 pc=0xa6ba84
github.com/lni/dragonboat/v3.(*execEngine).nodeWorkerMain(0x4000116090, 0x8)
/home/pi/go/pkg/mod/github.com/lni/dragonboat/[email protected]/execengine.go:804 +0x1d0 fp=0x4045a55f20 sp=0x4045a55d90 pc=0xa6b188
github.com/lni/dragonboat/v3.newExecEngine.func1()
/home/pi/go/pkg/mod/github.com/lni/dragonboat/[email protected]/execengine.go:663 +0x30 fp=0x4045a55f40 sp=0x4045a55f20 pc=0xa8c7d8
github.com/lni/goutils/syncutil.(*Stopper).runWorker.func1(0x40002eae80, 0x4000164170, 0x0, 0x0, 0x400020a020)
/home/pi/go/pkg/mod/github.com/lni/[email protected]/syncutil/stopper.go:104 +0x50 fp=0x4045a55fb0 sp=0x4045a55f40 pc=0xa26868
runtime.goexit()
/usr/local/go/src/runtime/asm_arm64.s:1148 +0x4 fp=0x4045a55fb0 sp=0x4045a55fb0 pc=0x5896cc
created by github.com/lni/goutils/syncutil.(*Stopper).runWorker
/home/pi/go/pkg/mod/github.com/lni/[email protected]/syncutil/stopper.go:94 +0x88
Steps to reproduce the behavior
Run on Raspberian 64 bit
The text was updated successfully, but these errors were encountered: