Skip to content
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

[BUG] Go Ethereum Does Not Adhere to Unsafe Usage Conventions With Go 1.14 Changes #20731

Closed
bonedaddy opened this issue Feb 29, 2020 · 15 comments · Fixed by #20747
Closed

[BUG] Go Ethereum Does Not Adhere to Unsafe Usage Conventions With Go 1.14 Changes #20731

bonedaddy opened this issue Feb 29, 2020 · 15 comments · Fixed by #20747

Comments

@bonedaddy
Copy link

bonedaddy commented Feb 29, 2020

System information

Geth version: 1.9.11
OS & Version: Linux
Commit hash : v1.9.11 release
Go Version: 1.14

Expected behaviour

Tests with race detection should run safely and CI passes

Actual behaviour

CI builds with -race fail because go1.14 introduces new detection methods to better validate usage of unsafe.Pointer

Steps to reproduce the behaviour

Write code that uses go-ethereum while using v1.14 of go. Write a test and run test with -race enabled

Backtrace

$ go test -race -short -coverprofile=coverage.txt ./...
fatal error: checkptr: unsafe pointer conversion
goroutine 1 [running, locked to thread]:
runtime.throw(0x11deb14, 0x23)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/panic.go:1112 +0x72 fp=0xc00010ba98 sp=0xc00010ba68 pc=0x44a082
runtime.checkptrAlignment(0xc0001522a9, 0x108c740, 0x1)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/checkptr.go:13 +0xd0 fp=0xc00010bac8 sp=0xc00010ba98 pc=0x41b6a0
golang.org/x/crypto/sha3.xorInUnaligned(0xc0001521c0, 0xc0001522a9, 0x88, 0xa8)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/xor_unaligned.go:13 +0x60 fp=0xc00010bb00 sp=0xc00010bac8 pc=0x6a7400
golang.org/x/crypto/sha3.(*state).permute(0xc0001521c0)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:84 +0x1d3 fp=0xc00010bb50 sp=0xc00010bb00 pc=0x6a5d23
golang.org/x/crypto/sha3.(*state).padAndPermute(0xc0001521c0, 0x1f41b01)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:117 +0x347 fp=0xc00010bbf8 sp=0xc00010bb50 pc=0x6a60e7
golang.org/x/crypto/sha3.(*state).Read(0xc0001521c0, 0xc000026860, 0x20, 0x20, 0x7faeebfe5108, 0x0, 0xc000152000)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:163 +0x2e0 fp=0xc00010bc88 sp=0xc00010bbf8 pc=0x6a6bb0
golang.org/x/crypto/sha3.(*state).Sum(0xc000152000, 0xc000026840, 0x0, 0x20, 0x0, 0x0, 0x0)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:190 +0x233 fp=0xc00010bd20 sp=0xc00010bc88 pc=0x6a6e13
github.com/ethereum/go-ethereum/crypto.Keccak256Hash(0xc00000ee80, 0x1, 0x1, 0x6ef8c092e64583ff, 0xc0ad6c991be0485b, 0x21b463e3b52f6201, 0xc00014a000)
	/home/travis/gopath/pkg/mod/github.com/ethereum/[email protected]/crypto/crypto.go:69 +0x1b6 fp=0xc00010bd88 sp=0xc00010bd20 pc=0x71afd6
github.com/ethereum/go-ethereum/trie.init()
	/home/travis/gopath/pkg/mod/github.com/ethereum/[email protected]/trie/trie.go:35 +0xc32 fp=0xc00010be68 sp=0xc00010bd88 pc=0x8142e2
runtime.doInit(0x1e62e00)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5414 +0x8a fp=0xc00010be98 sp=0xc00010be68 pc=0x4594ca
runtime.doInit(0x1e62540)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc00010bec8 sp=0xc00010be98 pc=0x459497
runtime.doInit(0x1e5c5e0)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc00010bef8 sp=0xc00010bec8 pc=0x459497
runtime.doInit(0x1e5dc60)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc00010bf28 sp=0xc00010bef8 pc=0x459497
runtime.doInit(0x1e5ea80)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc00010bf58 sp=0xc00010bf28 pc=0x459497
runtime.doInit(0x1e5d540)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc00010bf88 sp=0xc00010bf58 pc=0x459497
runtime.main()
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:190 +0x1ce fp=0xc00010bfe0 sp=0xc00010bf88 pc=0x44c68e
runtime.goexit()
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00010bfe8 sp=0xc00010bfe0 pc=0x47e151
FAIL	github.com/RTradeLtd/baple/backend	0.029s
?   	github.com/RTradeLtd/baple/bindings	[no test files]
?   	github.com/RTradeLtd/baple/cmd/baple	[no test files]
ok  	github.com/RTradeLtd/baple/config	0.019s	coverage: 87.5% of statements
ok  	github.com/RTradeLtd/baple/mongo	0.542s	coverage: 84.2% of statements
fatal error: checkptr: unsafe pointer conversion
goroutine 1 [running, locked to thread]:
runtime.throw(0xeedc81, 0x23)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/panic.go:1112 +0x72 fp=0xc0000b3a98 sp=0xc0000b3a68 pc=0x44a062
runtime.checkptrAlignment(0xc0000fe2a9, 0xdd7300, 0x1)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/checkptr.go:13 +0xd0 fp=0xc0000b3ac8 sp=0xc0000b3a98 pc=0x41b6a0
golang.org/x/crypto/sha3.xorInUnaligned(0xc0000fe1c0, 0xc0000fe2a9, 0x88, 0xa8)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/xor_unaligned.go:13 +0x60 fp=0xc0000b3b00 sp=0xc0000b3ac8 pc=0x69fbd0
golang.org/x/crypto/sha3.(*state).permute(0xc0000fe1c0)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:84 +0x1d3 fp=0xc0000b3b50 sp=0xc0000b3b00 pc=0x69e4f3
golang.org/x/crypto/sha3.(*state).padAndPermute(0xc0000fe1c0, 0x188f301)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:117 +0x347 fp=0xc0000b3bf8 sp=0xc0000b3b50 pc=0x69e8b7
golang.org/x/crypto/sha3.(*state).Read(0xc0000fe1c0, 0xc0000d6100, 0x20, 0x20, 0x7ff4f3b467d0, 0x0, 0xc0000fe000)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:163 +0x2e0 fp=0xc0000b3c88 sp=0xc0000b3bf8 pc=0x69f380
golang.org/x/crypto/sha3.(*state).Sum(0xc0000fe000, 0xc0000d60e0, 0x0, 0x20, 0x0, 0x0, 0x0)
	/home/travis/gopath/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:190 +0x233 fp=0xc0000b3d20 sp=0xc0000b3c88 pc=0x69f5e3
github.com/ethereum/go-ethereum/crypto.Keccak256Hash(0xc0000bce20, 0x1, 0x1, 0x6ef8c092e64583ff, 0xc0ad6c991be0485b, 0x21b463e3b52f6201, 0xc0000f6000)
	/home/travis/gopath/pkg/mod/github.com/ethereum/[email protected]/crypto/crypto.go:69 +0x1b6 fp=0xc0000b3d88 sp=0xc0000b3d20 pc=0x714ef6
github.com/ethereum/go-ethereum/trie.init()
	/home/travis/gopath/pkg/mod/github.com/ethereum/[email protected]/trie/trie.go:35 +0xc32 fp=0xc0000b3e68 sp=0xc0000b3d88 pc=0x812722
runtime.doInit(0x17bd1c0)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5414 +0x8a fp=0xc0000b3e98 sp=0xc0000b3e68 pc=0x45926a
runtime.doInit(0x17bc900)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc0000b3ec8 sp=0xc0000b3e98 pc=0x459237
runtime.doInit(0x17b75e0)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc0000b3ef8 sp=0xc0000b3ec8 pc=0x459237
runtime.doInit(0x17b8c00)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc0000b3f28 sp=0xc0000b3ef8 pc=0x459237
runtime.doInit(0x17b92c0)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc0000b3f58 sp=0xc0000b3f28 pc=0x459237
runtime.doInit(0x17b84e0)
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:5409 +0x57 fp=0xc0000b3f88 sp=0xc0000b3f58 pc=0x459237
runtime.main()
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/proc.go:190 +0x1ce fp=0xc0000b3fe0 sp=0xc0000b3f88 pc=0x44c66e
runtime.goexit()
	/home/travis/.gimme/versions/go1.14.linux.amd64/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc0000b3fe8 sp=0xc0000b3fe0 pc=0x47de41
FAIL	github.com/RTradeLtd/baple/testutils	0.027s
FAIL
The command "go test -race -short -coverprofile=coverage.txt ./..." exited with 1.
cache.2
store build cache````
@karalabe
Copy link
Member

karalabe commented Mar 2, 2020

This bug is in Go's crypto libs. Was fixed upstream (golang/crypto@c7e5f84), we need to update our dependency.

@bonedaddy
Copy link
Author

Ah okay, thanks.

@mvdan
Copy link

mvdan commented Mar 4, 2020

@karalabe are you sure? I'm still getting very similar panics, even though I'm using a very recent x/crypto version, after that fix:

fatal error: checkptr: unsafe pointer conversion

goroutine 11 [running]:
runtime.throw(0x310e7b2, 0x23)
	/usr/lib/go/src/runtime/panic.go:1112 +0x72 fp=0xc0005a1f18 sp=0xc0005a1ee8 pc=0xda50b2
runtime.checkptrAlignment(0xc0000f8785, 0x2d4fc60, 0x11)
	/usr/lib/go/src/runtime/checkptr.go:13 +0xd0 fp=0xc0005a1f48 sp=0xc0005a1f18 pc=0xd761d0
golang.org/x/crypto/sha3.xorInUnaligned(0xc00134afc0, 0xc0000f8785, 0x88, 0x2fb)
	/home/mvdan/go/pkg/mod/golang.org/x/[email protected]/sha3/xor_unaligned.go:21 +0x65 fp=0xc0005a1f88 sp=0xc0005a1f48 pc=0x108d765
golang.org/x/crypto/sha3.(*state).Write(0xc00134afc0, 0xc0000f8785, 0x26a, 0x2fb, 0x3, 0x0, 0x0)
	/home/mvdan/go/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:138 +0x19e fp=0xc0005a2028 sp=0xc0005a1f88 pc=0x108c43e
github.com/ethereum/go-ethereum/rlp.(*encbuf).toWriter(0xc0015d55e0, 0x7fbf607ccd78, 0xc00134afc0, 0x0, 0x0)
	/home/mvdan/go/pkg/mod/github.com/ethereum/[email protected]/rlp/encode.go:240 +0x3f2 fp=0xc0005a20d8 sp=0xc0005a2028 pc=0x10acb72
github.com/ethereum/go-ethereum/rlp.Encode(0x7fbf607ccd78, 0xc00134afc0, 0x2ee2020, 0xc0004be6c0, 0x0, 0x0)
	/home/mvdan/go/pkg/mod/github.com/ethereum/[email protected]/rlp/encode.go:65 +0x1d9 fp=0xc0005a2180 sp=0xc0005a20d8 pc=0x10aab69
github.com/ethereum/go-ethereum/core/types.rlpHash(0x2ee2020, 0xc0004be6c0, 0x0, 0xb, 0xc0011ddb20, 0x30d8a7d)

Note that I don't know if the bug is in this module, or once again in the crypto module.

tinnendo pushed a commit to perun-network/go-perun_archived that referenced this issue Mar 6, 2020
This seems to be a bug in go's crypto lib, which is used by go-ethereum
ethereum/go-ethereum#20731

From the Go 1.14 release notes:

This release adds -d=checkptr as a compile-time option for adding
instrumentation to check that Go code is following unsafe.Pointer safety
rules dynamically. This option is enabled by default (except on Windows)
with the -race or -msan flags, and can be disabled with
-gcflags=all=-d=checkptr=0. Specifically, -d=checkptr checks the
following:

When converting unsafe.Pointer to *T, the resulting pointer must be
aligned appropriately for T.
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.

Using -d=checkptr is not currently recommended on Windows because it
causes false alerts in the standard library.
@RmbRT
Copy link

RmbRT commented Mar 6, 2020

Probable cause
From the Go 1.14 release notes:

This release adds -d=checkptr as a compile-time option for adding instrumentation to check that Go code is following unsafe.Pointer safety rules dynamically. This option is enabled by default (except on Windows) with the -race or -msan flags, and can be disabled with -gcflags=all=-d=checkptr=0. Specifically, -d=checkptr checks the following:

  • When converting unsafe.Pointer to *T, the resulting pointer must be aligned appropriately for T.
    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.

Using -d=checkptr is not currently recommended on Windows because it causes false alerts in the standard library.

It seems this feature not only breaks on windows, but also on GNU+Linux.
It is only active in race testing, it seems.

Fix
Add -gcflags=all=-d=checkptr=0 to the pipeline.

@mvdan
Copy link

mvdan commented Mar 6, 2020

The fix is not to disable the check entirely, unless you're certain you've found a bug in the checkptr feature. If you're going to be disabling checks, you might as well not use -race at all.

@RmbRT
Copy link

RmbRT commented Mar 6, 2020

@mvdan The problem occurs within golang's sha3 implementation. It's not something we as developers have control over. Normally, it would be bad style to do this, but the Go team seems to have released a broken version.

@karalabe
Copy link
Member

karalabe commented Mar 6, 2020

Hmm, lemme try and repro this locally. If it's indeed a bug in Go, I'm sure they'd fix is quite quickly if reported. Just would be nice to repro it without all our code in the soup.

@karalabe
Copy link
Member

karalabe commented Mar 6, 2020

@mvdan @RmbRT I'm still kind of confident that it's a bug in Go crypto, and that it's already been fixed upstream:

Running the trie tests with 1.14 on current codebase:

$ go test -race ./trie --count=1
fatal error: checkptr: unsafe pointer conversion

goroutine 1 [running, locked to thread]:
runtime.throw(0x902edb, 0x23)
	/opt/google/go/src/runtime/panic.go:1112 +0x72 fp=0xc00012bb58 sp=0xc00012bb28 pc=0x446972
runtime.checkptrAlignment(0xc000178469, 0x8889c0, 0x1)
	/opt/google/go/src/runtime/checkptr.go:13 +0xd0 fp=0xc00012bb88 sp=0xc00012bb58 pc=0x418130
golang.org/x/crypto/sha3.xorInUnaligned(0xc000178380, 0xc000178469, 0x88, 0xa8)
	/work/pkg/mod/golang.org/x/[email protected]/sha3/xor_unaligned.go:13 +0x60 fp=0xc00012bbc0 sp=0xc00012bb88 pc=0x66f8b0
golang.org/x/crypto/sha3.(*state).permute(0xc000178380)
	/work/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:84 +0x1d3 fp=0xc00012bc10 sp=0xc00012bbc0 pc=0x66e1d3
golang.org/x/crypto/sha3.(*state).padAndPermute(0xc000178380, 0xbe2c01)
	/work/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:117 +0x347 fp=0xc00012bcb8 sp=0xc00012bc10 pc=0x66e597
golang.org/x/crypto/sha3.(*state).Read(0xc000178380, 0xc00014e240, 0x20, 0x20, 0x7fa3cb72ae98, 0x0, 0xc0001781c0)
	/work/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:163 +0x2e0 fp=0xc00012bd48 sp=0xc00012bcb8 pc=0x66f060
golang.org/x/crypto/sha3.(*state).Sum(0xc0001781c0, 0xc00014e220, 0x0, 0x20, 0x0, 0x0, 0x0)
	/work/pkg/mod/golang.org/x/[email protected]/sha3/sha3.go:190 +0x233 fp=0xc00012bde0 sp=0xc00012bd48 pc=0x66f2c3
github.com/ethereum/go-ethereum/crypto.Keccak256Hash(0xc000134f20, 0x1, 0x1, 0x6ef8c092e64583ff, 0xc0ad6c991be0485b, 0x21b463e3b52f6201, 0x7bffd8)
	/work/src/github.com/ethereum/go-ethereum/crypto/crypto.go:69 +0x1b6 fp=0xc00012be48 sp=0xc00012bde0 pc=0x716376
github.com/ethereum/go-ethereum/trie.init()
	/work/src/github.com/ethereum/go-ethereum/trie/trie.go:35 +0xc32 fp=0xc00012bf28 sp=0xc00012be48 pc=0x8170b2
runtime.doInit(0xbd1e60)
	/opt/google/go/src/runtime/proc.go:5414 +0x8a fp=0xc00012bf58 sp=0xc00012bf28 pc=0x455b7a
runtime.doInit(0xbcd400)
	/opt/google/go/src/runtime/proc.go:5409 +0x57 fp=0xc00012bf88 sp=0xc00012bf58 pc=0x455b47
runtime.main()
	/opt/google/go/src/runtime/proc.go:190 +0x1ce fp=0xc00012bfe0 sp=0xc00012bf88 pc=0x448f7e
runtime.goexit()
	/opt/google/go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00012bfe8 sp=0xc00012bfe0 pc=0x479e71
FAIL	github.com/ethereum/go-ethereum/trie	0.026s
FAIL

Update the crpyto modules:

$ go get -u golang.org/x/crypto/...

Rerun the trie tests:

$ go test -race ./trie --count=1
ok  	github.com/ethereum/go-ethereum/trie	39.473s

@karalabe
Copy link
Member

karalabe commented Mar 6, 2020

I'll open a PR to update the crypto package, will probably solve a lot of issues if you don't have to jump through hoops to replace the package yourself.

@mvdan
Copy link

mvdan commented Mar 6, 2020

@karalabe just so we are on the same page, note that my panic trace contains an up-to-date version of the module containing the sha3 package. That version contains the fix you're referencing. I'm pretty sure we're talking about different issues here, even though they both surface because of 1.14 and the same package.

@karalabe
Copy link
Member

karalabe commented Mar 6, 2020

@mvdan Oh, that's super interesting, I can repro that issue with updated crypto too. Funky, lemme dig deeper :)

@mvdan
Copy link

mvdan commented Mar 6, 2020

Precisely. Even if you update the version, the check can still fail.

@karalabe
Copy link
Member

karalabe commented Mar 6, 2020

The smallest repro I have currently is

package racerepro

import (
	"testing"

	"github.com/ethereum/go-ethereum/rlp"
	"golang.org/x/crypto/sha3"
)

type S struct {
	F1 [2048]byte
	F2 [32]byte
}

func TestRacePanic(t *testing.T) {
	rlp.Encode(sha3.NewLegacyKeccak256(), new(S))
}

I still need to nuke out parts of rlp to check if the bug is us or Go (high chance it's us at this point).

@karalabe
Copy link
Member

karalabe commented Mar 6, 2020

💥 Bug's in Go

package racerepro

import (
	"encoding/hex"
	"testing"

	"golang.org/x/crypto/sha3"
)

func TestRacePanic(t *testing.T) {
	b1, _ := hex.DecodeString("f90824")
	b2, _ := hex.DecodeString("b908000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000")

	hasher := sha3.NewLegacyKeccak256()
	hasher.Write(b1)
	hasher.Write(b2)
}

@mvdan
Copy link

mvdan commented Mar 6, 2020

Nice find. Good to see that the go team is already aware of the bug. It's unfortunate I didn't find the existing issue when googling just a couple of days ago.

tinnendo pushed a commit to perun-network/go-perun_archived that referenced this issue Mar 11, 2020
This seems to be a bug in go's crypto lib, which is used by go-ethereum
ethereum/go-ethereum#20731

From the Go 1.14 release notes:

This release adds -d=checkptr as a compile-time option for adding
instrumentation to check that Go code is following unsafe.Pointer safety
rules dynamically. This option is enabled by default (except on Windows)
with the -race or -msan flags, and can be disabled with
-gcflags=all=-d=checkptr=0. Specifically, -d=checkptr checks the
following:

When converting unsafe.Pointer to *T, the resulting pointer must be
aligned appropriately for T.
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.

Using -d=checkptr is not currently recommended on Windows because it
causes false alerts in the standard library.
manoranjith pushed a commit to boschresearch/go-perun-archived that referenced this issue Aug 5, 2020
This seems to be a bug in go's crypto lib, which is used by go-ethereum
ethereum/go-ethereum#20731

From the Go 1.14 release notes:

This release adds -d=checkptr as a compile-time option for adding
instrumentation to check that Go code is following unsafe.Pointer safety
rules dynamically. This option is enabled by default (except on Windows)
with the -race or -msan flags, and can be disabled with
-gcflags=all=-d=checkptr=0. Specifically, -d=checkptr checks the
following:

When converting unsafe.Pointer to *T, the resulting pointer must be
aligned appropriately for T.
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.

Using -d=checkptr is not currently recommended on Windows because it
causes false alerts in the standard library.  
  
Signed-off-by: Sebastian Stammler <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants