badger: ARMv7 segmentation fault in oracle.readTs when calling loadUint64

I am facing an issue running badger on an ARMv7 architecture. The minimal test case below works quite fine on an amd64 machine but, unfortunately, not on ARMv7 32bit.

The trace below shows that the issue originates in atomic.loadUint64() but I also run basic atomic operations tests against the golang runtime, and they work fine on this architecture.

It looks to me that the underlying memory of oracle.curRead somehow vanishes but I am not sure.

Below you find also a strace trace. There the segmentation fault happens after the madvise, but I am not sure if this is related.

Badger version: 1.0.1 (89689ef36cae26ae094cb5ea79b7400d839f2d68) golang version: 1.8.5 and 1.9.2

Test case:

func TestPersistentCache_DirectBadger(t *testing.T) {
	dir, err := ioutil.TempDir("", "")
	if err != nil {
		t.Fatal(err)
	}
	defer os.RemoveAll(dir)

	config := badger.DefaultOptions
	config.TableLoadingMode = options.MemoryMap
	config.ValueLogFileSize = 16 << 20
	config.LevelOneSize = 8 << 20
	config.MaxTableSize = 2 << 20
	config.Dir = dir
	config.ValueDir = dir
	config.SyncWrites = false

	db, err := badger.Open(config)
	if err != nil {
		t.Fatalf("cannot open db at location %s: %v", dir, err)
	}

	err = db.View(func(txn *badger.Txn) error { return nil })

	if err != nil {
		t.Fatal(err)
	}

	if err = db.Close(); err != nil {
		t.Fatal(err)
	}
}
=== RUN   TestPersistentCache_DirectBadger
--- FAIL: TestPersistentCache_DirectBadger (0.01s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x4 pc=0x1150c]

goroutine 5 [running]:
testing.tRunner.func1(0x10a793b0)
        /usr/lib/go/src/testing/testing.go:711 +0x2a0
panic(0x3e4bd8, 0x6bb478)
        /usr/lib/go/src/runtime/panic.go:491 +0x204
sync/atomic.loadUint64(0x10a483cc, 0x200000, 0x0)
        /usr/lib/go/src/sync/atomic/64bit_arm.go:10 +0x3c
github.com/grid-x/client/vendor/github.com/dgraph-io/badger.(*oracle).readTs(0x10a483c0, 0x14, 0x5)
        /home/robert/Projects/gridx/client/src/github.com/grid-x/client/vendor/github.com/dgraph-io/badger/transaction.go:87 +0x3c
github.com/grid-x/client/vendor/github.com/dgraph-io/badger.(*DB).NewTransaction(0x10b06000, 0x0, 0x4cccc)
        /home/robert/Projects/gridx/client/src/github.com/grid-x/client/vendor/github.com/dgraph-io/badger/transaction.go:440 +0x20
github.com/grid-x/client/vendor/github.com/dgraph-io/badger.(*DB).View(0x10b06000, 0x464e20, 0x0, 0x0)
        /home/robert/Projects/gridx/client/src/github.com/grid-x/client/vendor/github.com/dgraph-io/badger/transaction.go:457 +0x3c
command-line-arguments.TestPersistentCache_DirectBadger(0x10a793b0)
        /home/robert/Projects/gridx/client/src/github.com/grid-x/client/pkg/cache/persistent_cache_test.go:64 +0x1e8
testing.tRunner(0x10a793b0, 0x464e24)
        /usr/lib/go/src/testing/testing.go:746 +0xb0
created by testing.(*T).Run
        /usr/lib/go/src/testing/testing.go:789 +0x258

strace:

[pid 15075] mmap2(NULL, 33554432, PROT_READ, MAP_SHARED, 6, 0) = 0xb4dff000                                   
[pid 15075] madvise(0xb4dff000, 33554432, MADV_RANDOM) = 0                     
[pid 15075] clock_gettime(CLOCK_MONOTONIC, {tv_sec=69709, tv_nsec=217038306}) = 0                            
[pid 15075] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} ---
[pid 15075] rt_sigreturn()              = 0                                       

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 35 (18 by maintainers)

Commits related to this issue

Most upvoted comments

Ok applied the last patch. PR #318 is now open.

As per https://golang.org/pkg/sync/atomic/

Bugs ☞ On x86-32, the 64-bit functions use instructions unavailable before the Pentium MMX.

On non-Linux ARM, the 64-bit functions use instructions unavailable before the ARMv6k core.

On both ARM and x86-32, it is the caller’s responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a variable or in an allocated struct, array, or slice can be relied upon to be 64-bit aligned.