Details
-
Bug
-
Resolution: Fixed
-
Major
-
7.6.0
-
Untriaged
-
0
-
Unknown
Description
What's the issue?
When trying to create a MagmaDBRecovery for a magma shard that has no vBuckets in it we get a segmentation fault:
al error: unexpected signal during runtime execution
|
[signal SIGSEGV: segmentation violation code=0x2 addr=0xfffffffffffffffe pc=0x10204ea58]runtime stack: |
runtime.throw({0x100ca7134?, 0x100cd7e80?}) |
/opt/homebrew/Cellar/go/1.20.6/libexec/src/runtime/panic.go:1047 +0x40 fp=0x16f7da070 sp=0x16f7da040 pc=0x10065b500 |
runtime.sigpanic()
|
/opt/homebrew/Cellar/go/1.20.6/libexec/src/runtime/signal_unix.go:825 +0x244 fp=0x16f7da0b0 sp=0x16f7da070 pc=0x1006733e4goroutine 37 [syscall]: |
runtime.cgocall(0x100c77e34, 0x14000077d88) |
/opt/homebrew/Cellar/go/1.20.6/libexec/src/runtime/cgocall.go:157 +0x54 fp=0x14000077d50 sp=0x14000077d10 pc=0x100628f14 |
github.com/couchbase/backup/magma._Cfunc_NewMagmaDBRecovery(0x130105ec0) |
_cgo_gotypes.go:303 +0x38 fp=0x14000077d80 sp=0x14000077d50 pc=0x100c650e8 |
github.com/couchbase/backup/magma.NewShardReader({0x100c89bc1, 0x15}) |
/Users/gvidasrazevicius/Documents/Rep/source2/backup/magma/magma.go:50 +0x184 fp=0x14000077e30 sp=0x14000077d80 pc=0x100c654c4 |
github.com/couchbase/backup/recovery.NewMagmaStore({0x100c89bc1?, 0x3d?}) |
/Users/gvidasrazevicius/Documents/Rep/source2/backup/recovery/magma.go:14 +0x20 fp=0x14000077e80 sp=0x14000077e30 pc=0x100c6abf0 |
github.com/couchbase/backup/recovery.TestGetAllFiles.func1(0x0?) |
/Users/gvidasrazevicius/Documents/Rep/source2/backup/recovery/magma_test.go:35 +0x40 fp=0x14000077f60 sp=0x14000077e80 pc=0x100c6ecd0 |
testing.tRunner(0x140004c4b60, 0x140003cdd80) |
/opt/homebrew/Cellar/go/1.20.6/libexec/src/testing/testing.go:1576 +0x10c fp=0x14000077fb0 sp=0x14000077f60 pc=0x10073de6c |
testing.(*T).Run.func1()
|
/opt/homebrew/Cellar/go/1.20.6/libexec/src/testing/testing.go:1629 +0x2c fp=0x14000077fd0 sp=0x14000077fb0 pc=0x10073ecdc |
runtime.goexit()
|
/opt/homebrew/Cellar/go/1.20.6/libexec/src/runtime/asm_arm64.s:1172 +0x4 fp=0x14000077fd0 sp=0x14000077fd0 pc=0x1006918d4 |
created by testing.(*T).Run
|
/opt/homebrew/Cellar/go/1.20.6/libexec/src/testing/testing.go:1629 +0x368 |
|
The bucket data folder structure that we tried creating the MagmaDBRecovery for is this:
.
|
├── collections.manifest
|
├── magma.0 |
│ ├── config.json
|
│ ├── kvstore-0 |
│ │ └── rev-000000001 |
│ │ ├── file.lock
|
│ │ ├── keyIndex
|
│ │ │ └── config.json
|
│ │ ├── localIndex
|
│ │ │ └── config.json
|
│ │ └── seqIndex
|
│ │ └── config.json
|
│ └── wal
|
│ └── wal.1 |
├── magma.1 |
│ ├── config.json
|
│ └── wal
|
│ └── wal.1 |
├── magmaShardCount
|
├── master.couch.1 |
├── stats.json
|
└── stats.json.old
|
The MagmaDBRecovery was created successfully for magma.0 however trying to create it for the magma.1 shard, which has no vBuckets, resulted in the segmentation fault.
Recreation steps:
1. Make sure the system you are on has more than 1 CPU core since the number of shards is equal to the number of CPU cores on the system running the cluster.
2. On a local copy of couchbase server run the ./cluster_run script located in the ns_server directory, the full command is:
| ./cluster_run --num_vbuckets 1 |
or after starting couchbase server the amount of vBuckets can also be set by calling this endpoint:
| curl -X POST -u Administrator:asdasd http://localhost:9000/diag/eval -d "ns_config:set(couchbase_num_vbuckets_default, 1)." |
3. In the same ns_server directory run this script with the these parameters:
| ./cluster_connect -S magma -r 0 -n 1 |
4. With this setup we can now try to create the MagmaDBRecovery for the default bucket which should fail with a segmentation fault.
Investigation:
Would be good to know if there is something the user of the API should do to avoid this in case there are measures against it in place. If not it would be great for this case to be handled better.