3

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
runtime.sigpanic()
    /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
runtime.goexit()
    /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!

Improve this question
4
  • 1
    There were some attacks to Ethereum network last week, you should upgrade to v1.6.5. If the bug appears again please report to go-ethereum repository in github.
    – Ismael ♦
    Commented Jun 7, 2017 at 22:31
  • Updated to 1.6.5 but still same problem
    – Juan Ignacio Pérez Sacristán
    Commented Jun 15, 2017 at 8:57
  • 1
    I've seen backtraces in my nodes, but they appear from time to time and seems to be invalid block/tx, but geth didn't crash and continued working without problem. If you can discard a hardware problem, then you cab report them to developers github.com/ethereum/go-ethereum/issues.
    – Ismael ♦
    Commented Jun 15, 2017 at 14:04
  • Thx. I have submitted it at github.com/ethereum/go-ethereum/issues/14629
    – Juan Ignacio Pérez Sacristán
    Commented Jun 15, 2017 at 17:06

2 Answers 2

Reset to default
4
+50

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.

Improve this answer
1
  • 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
    Commented Jun 15, 2017 at 8:56
1

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

Improve this answer
4
  • Yes, it's true. My nodes running 1.7.2 hang once a day or so when mining
    – Juan Ignacio Pérez Sacristán
    Commented Nov 27, 2017 at 8:33
  • 1
    I think I saw a comment float by, stating that this was recently fixed (circa January 2018)
    – Linas
    Commented Feb 10, 2018 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
    Commented Feb 16, 2018 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
    Commented Feb 18, 2018 at 0:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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