Since upgraded to version 1.6.1, Geth node hangs form time to time (once a week) with following fatal error:

fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x7f6453b72c88 pc=0x461097]

goroutine 1500070 [running]:
runtime.throw(0xe9b327, 0x5)
    /home/travis/.gimme/versions/go1.8.1.linux.amd64/src/runtime/panic.go:596 +0x95 fp=0xc43095a9f0 sp=0xc43095a9d0
    /home/travis/.gimme/versions/go1.8.1.linux.amd64/src/runtime/signal_unix.go:297 +0x28c fp=0xc43095aa40 sp=0xc43095a9f0
runtime.memmove(0xc423ad8b80, 0x7f6453b72c88, 0x40)
    /home/travis/.gimme/versions/go1.8.1.linux.amd64/src/runtime/memmove_amd64.s:184 +0x657 fp=0xc43095aa48 sp=0xc43095aa40
github.com/ethereum/go-ethereum/consensus/ethash.hashimoto(0xc43095ad78, 0x20, 0x20, 0x3ff85f426cae9afa, 0x50ffff80, 0xc448b3abe0, 0xc43095ac48, 0x40b944, 0xd2b540, 0xc427ef5320, ...)
    /home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/algorithm.go:314 +0x36e fp=0xc43095abe0 sp=0xc43095aa48
github.com/ethereum/go-ethereum/consensus/ethash.hashimotoFull(0x7f6453000008, 0x143fffe0, 0x143fffe0, 0xc43095ad78, 0x20, 0x20, 0x3ff85f426cae9afa, 0xc448b3ab20, 0x20, 0x20, ...)
    /home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/algorithm.go:357 +0xbe fp=0xc43095ac58 sp=0xc43095abe0
github.com/ethereum/go-ethereum/consensus/ethash.(*Ethash).mine(0xc420fc0b40, 0xc43363c990, 0x0, 0x3ff85f426cac4155, 0xc427ef5320, 0xc427ef5380)
    /home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/sealer.go:130 +0x451 fp=0xc43095af68 sp=0xc43095ac58
github.com/ethereum/go-ethereum/consensus/ethash.(*Ethash).Seal.func1(0xc420695aa0, 0xc420fc0b40, 0xc43363c990, 0xc427ef5320, 0xc427ef5380, 0x0, 0x3ff85f426cac4155)
    /home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/sealer.go:72 +0x87 fp=0xc43095afa8 sp=0xc43095af68
    /home/travis/.gimme/versions/go1.8.1.linux.amd64/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc43095afb0 sp=0xc43095afa8
created by github.com/ethereum/go-ethereum/consensus/ethash.(*Ethash).Seal
    /home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/sealer.go:73 +0x1d7

Any idea what is the reason for this error? how to fix? Thx!


Geth v1.6.1 is now outdated. Update to Geth v1.6.5 (nicknamed Hat Trick), released to prevent a recent DOS attack on the mainnet. If the problem persists then report it via the go-ethereum GitHub repo: https://github.com/ethereum/go-ethereum

According to the Ethereum releases page, https://github.com/ethereum/go-ethereum/releases, Geth v1.6.1 was released May 4th. Your best bet at a fix would be to update your client, and stay current with the latest releases. It's entirely possible that whatever caused this error has been fixed since 1.6.1 anyways.

As far as the bug itself, according to the stacktrace everything goes wrong here: /../src/github.com/ethereum/go-ethereum/consensus/ethash/algorithm.go:314

The revision history in GitHub shows that the last revision to the file was in early May again, so the condition on line 314 that your client blows up on hasn't been changed with subsequent releases:

for j := uint32(0); j < mixBytes/hashBytes; j++ {
    copy(temp[j*hashWords:], lookup(2*parent+j))

I haven't looked through the known issues, but based off of the minimal revision history, I'm guessing that if it is a bug it would be somewhere else in the client. In general I would update your client, and if you're still having issues try regenerating your DAG file, perhaps it's corrupted somehow. If the issue persists after that, post an issue on the repo.

  • Updated to geth 1.6.5 and still same problem ... unexpected fault address 0x7fcb56135308 ... fatal error: fault ... [signal SIGSEGV: segmentation violation code=0x1 addr=0x7fcb56135308 pc=0x461137] ... – Juan Ignacio Pérez Sacristán Jun 15 '17 at 8:56

This bug continues to affect clients as new as 1.7.2 and is reported here: https://github.com/ethereum/go-ethereum/issues/14552

  • Yes, it's true. My nodes running 1.7.2 hang once a day or so when mining – Juan Ignacio Pérez Sacristán Nov 27 '17 at 8:33
  • 1
    I think I saw a comment float by, stating that this was recently fixed (circa January 2018) – Linas Feb 10 '18 at 6:11
  • @Linas, can you please be more specific about the fix? I just cloned and built geth and am running into the core dump today -- though I can't guarantee it's identical to that reported here. – Fred Douglis Feb 16 '18 at 22:36
  • Beats me. I notice you commented on github. I can't tell if your new stack trace is the same as the old one. If you have a different stack trace, you should open a different issue. It gets very confusing, very quick, if the same github issue is used to report different problems. The original crash was always in memmove, in hashimoto. Your crash seems to be in a different place. – Linas Feb 18 '18 at 0:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.