memdb: compatible with Go 1.14's checkptr

[bobotu]

What problem does this PR solve?

The Go 1.14 introduces new instrumentation to check that Go code is following unsafe.Pointer safety rules dynamically. The new flag -d=checkptr is enabled by default with the -race or -msan flags.

Specifically, -d=checkptr checks the following:

1. When converting unsafe.Pointer to *T, the resulting pointer must be aligned appropriately for T.
2. If the result of pointer arithmetic points into a Go heap object, one of the unsafe.Pointer-typed operands must point into the same object.

So if you run unit test with -race in Go 1.14 you will get a panic like

fatal error: checkptr: unsafe pointer conversion
goroutine 1 [running]:
runtime.throw(0x6bbf63a, 0x23)
	/usr/local/go/src/runtime/panic.go:1112 +0x72 fp=0xc000e0bcf8 sp=0xc000e0bcc8 pc=0x40368e2
runtime.checkptrAlignment(0xc00065f1bf, 0x6981ba0, 0x1)
	/usr/local/go/src/runtime/checkptr.go:13 +0xd0 fp=0xc000e0bd28 sp=0xc000e0bcf8 pc=0x4008710
github.com/pingcap/tidb/kv/memdb.(*DB).newNode(0xc000de28a0, 0xc000de2870, 0xc00005d530, 0x1b, 0x23, 0xc0001b0300, 0x10, 0x10, 0x1, 0x0, ...)
	/Users/tangliu/program/go/pkg/mod/github.com/pingcap/tidb@v1.1.0-beta.0.20200223044457-aedea3ec5e1e/kv/memdb/memdb.go:300 +0xbe fp=0xc000e0bda8 sp=0xc000e0bd28 pc=0x4b3b05e
github.com/pingcap/tidb/kv/memdb.(*DB).Put(0xc000de28a0, 0xc00005d530, 0x1b, 0x23, 0xc0001b0300, 0x10, 0x10, 0x6898b01)
	/Users/tangliu/program/go/pkg/mod/github.com/pingcap/tidb@v1.1.0-beta.0.20200223044457-aedea3ec5e1e/kv/memdb/memdb.go:91 +0x2fb fp=0xc000e0c0a8 sp=0xc000e0bda8 pc=0x4b390bb
github.com/pingcap/tidb/kv.(*memDbBuffer).Set(0xc000da1fc0, 0xc00005d530, 0x1b, 0x23, 0xc0001b0300, 0x10, 0x10, 0x6614180, 0x0)
	/Users/tangliu/program/go/pkg/mod/github.com/pingcap/tidb@v1.1.0-beta.0.20200223044457-aedea3ec5e1e/kv/memdb_buffer.go:104 +0x3fd fp=0xc000e0c1a0 sp=0xc000e0c0a8 pc=0x4b3dcdd
github.com/pingcap/tidb/kv.(*lazyMemBuffer).Set(0xc000bfef00, 0xc00005d530, 0x1b, 0x23, 0xc0001b0300, 0x10, 0x10, 0xaa592f0, 0x0)
	/Users/tangliu/program/go/pkg/mod/github.com/pingcap/tidb@v1.1.0-beta.0.20200223044457-aedea3ec5e1e/kv/union_store.go:141 +0xb5 fp=0xc000e0c208 sp=0xc000e0c1a0 pc=0x4b41535
github.com/pingcap/tidb/kv.(*unionStore).Set(0xc000bfef40, 0xc00005d530, 0x1b, 0x23, 0xc0001b0300, 0x10, 0x10, 0xc0001b030f, 0x10)
	<autogenerated>:1 +0xcd fp=0xc000e0c280 sp=0xc000e0c208 pc=0x4b4403d
github.com/pingcap/tidb/store/tikv.(*tikvTxn).Set(0xc000ad98c0, 0xc00005d530, 0x1b, 0x23, 0xc0001b0300, 0x10, 0x10, 0x0, 0x0)

What is changed and how it works?

In fact, the current implementation does not really cause illegal memory access. The node struct is actually a variable-sized struct, the nexts array is dynamically allocated according to the node's height. But checkptrAlignment will use the size defined by the struct, which is usually larger than the actual size of the object.

As a result, when Go's checker check the memory boundary according to rule 2, it will find some bytes in the node.nexts doesn't in the memory space returned by the allocator.

To address this problem, I modified the definition of node struct, change nexts array to nextsBase. Because each node always has at least one element in nexts, the checker will never fail.

The rule 1 is easy to address, just align the allocation in arenaBlock.

Check List

Tests

• Manual test (add detailed scripts or steps below)
  • Run test with -race using Go 1.14

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@899c274). Click here to learn what that means.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             master     #14972   +/-   ##
===========================================
  Coverage          ?   80.3461%           
===========================================
  Files             ?        502           
  Lines             ?     131455           
  Branches          ?          0           
===========================================
  Hits              ?     105619           
  Misses            ?      17500           
  Partials          ?       8336

[coocood]

LGTM

[tiancaiamao]

LGTM

Some of my personal projects might also be influenced by Go 1.14, I miss C so much...

[tiancaiamao]

/run-all-tests

[jackysp]

/merge

[sre-bot]

/run-all-tests

[sre-bot]

@bobotu merge failed.

[tiancaiamao]

/merge

[sre-bot]

Your auto merge job has been accepted, waiting for 14962

[sre-bot]

/run-all-tests

[tiancaiamao]

/merge

[sre-bot]

/run-all-tests