Geth 1.6.1 hängt und gibt den schwerwiegenden Fehler „unerwartete Fehleradresse“ aus

Seit dem Upgrade auf Version 1.6.1 hängt der Geth-Knoten von Zeit zu Zeit (einmal pro Woche) mit folgendem schwerwiegenden Fehler:

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

Irgendeine Idee, was der Grund für diesen Fehler ist? wie repariert man? Danke!

Letzte Woche gab es einige Angriffe auf das Ethereum-Netzwerk, Sie sollten auf v1.6.5 aktualisieren. Wenn der Fehler erneut auftritt, melden Sie ihn bitte an das go-ethereum-Repository in github.
Aktualisiert auf 1.6.5, aber immer noch das gleiche Problem
Ich habe Backtraces in meinen Knoten gesehen, aber sie tauchen von Zeit zu Zeit auf und scheinen ungültige Blöcke/TX zu sein, aber Geth ist nicht abgestürzt und hat ohne Probleme weitergearbeitet. Wenn Sie ein Hardwareproblem beseitigen können, melden Sie es den Entwicklern unter github.com/ethereum/go-ethereum/issues .

Antworten (2)

Geth v1.6.1ist mittlerweile veraltet. Update auf Geth v1.6.5(Spitzname Hat Trick), veröffentlicht, um einen kürzlichen DOS-Angriff auf das Mainnet zu verhindern. Wenn das Problem weiterhin besteht, melden Sie es über das GitHub-Repo von go-ethereum: https://github.com/ethereum/go-ethereum

Laut der Veröffentlichungsseite von Ethereum wurde https://github.com/ethereum/go-ethereum/releasesGeth v1.6.1 am 4. Mai veröffentlicht . Ihre beste Lösung wäre, Ihren Client zu aktualisieren und mit den neuesten Versionen auf dem Laufenden zu bleiben. Es ist durchaus möglich, dass die Ursache für diesen Fehler 1.6.1sowieso behoben wurde.

Was den Fehler selbst betrifft, so läuft hier laut Stacktrace alles schief:/../src/github.com/ethereum/go-ethereum/consensus/ethash/algorithm.go:314

Der Überarbeitungsverlauf in GitHub zeigt, dass die letzte Überarbeitung der Datei wieder Anfang Mai war, sodass die Bedingung in Zeile 314, bei der Ihr Client explodiert, bei nachfolgenden Versionen nicht geändert wurde:

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

Ich habe die bekannten Probleme nicht durchgesehen, aber basierend auf dem minimalen Revisionsverlauf vermute ich, dass, wenn es sich um einen Fehler handelt, er sich an einer anderen Stelle im Client befindet. Im Allgemeinen würde ich Ihren Client aktualisieren, und wenn Sie immer noch Probleme haben, versuchen Sie, Ihre DAG-Datei neu zu generieren, vielleicht ist sie irgendwie beschädigt. Wenn das Problem danach weiterhin besteht, posten Sie ein Problem im Repo.

Aktualisiert auf geth 1.6.5 und immer noch das gleiche Problem ... unerwartete Fehleradresse 0x7fcb56135308 ... fataler Fehler: Fehler ... [Signal SIGSEGV: Segmentation Violation Code=0x1 addr=0x7fcb56135308 pc=0x461137] ...

Dieser Fehler betrifft weiterhin Clients ab Version 1.7.2 und wird hier gemeldet: https://github.com/ethereum/go-ethereum/issues/14552

Ja, es ist wahr. Meine Knoten, auf denen 1.7.2 ausgeführt wird, hängen etwa einmal am Tag beim Mining
Ich glaube, ich habe einen Kommentar vorbeischweben sehen, der besagt, dass dies kürzlich behoben wurde (ca. Januar 2018).
@Linas, kannst du bitte genauer auf die Lösung eingehen? Ich habe gerade geth geklont und gebaut und stoße heute auf den Core-Dump - obwohl ich nicht garantieren kann, dass er mit dem hier berichteten identisch ist.
Schlägt mich. Ich sehe, dass Sie Github kommentiert haben. Ich kann nicht sagen, ob Ihr neuer Stack-Trace derselbe ist wie der alte. Wenn Sie einen anderen Stack-Trace haben, sollten Sie ein anderes Problem öffnen. Es wird sehr schnell sehr verwirrend, wenn dasselbe Github-Problem verwendet wird, um verschiedene Probleme zu melden. Der ursprüngliche Absturz war immer in memmove, in hashimoto. Ihr Absturz scheint an einem anderen Ort zu sein.
Geth 1.6.1 hängt und gibt den schwerwiegenden Fehler „unerwartete Fehleradresse“ aus
AntwortenHierDatenschutz-Bestimmungen1y, 0v