Closed FDN73 closed 6 years ago
Is this reproducible? Does this happen all the time?
Hello, no - when I restarted geth, it worked.
That error messages is really peculiar because it originates from C code. Go cannot crash like that. This means that either the USB library crashed or the crypto lib (unlikely). Please post further messages here if it happens again.
I'll try to wait some time (light chain not updated for a few days) and then start it to see if it happens again.
I just got the same (on Android - v 1.6.1):
Tried again today after 4 days of inactivity, all good. I think it was some conflict with the previous chain generated by geth-linux-amd64-1.5.4-b70acf3c , restarting geth seems to have cleaned the chain. Not sure why it happened to ligi on android too - has geth been updated recently on walleth?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I've launched geth in light mode after at least two months I've not been using it on this machine (so a previous not fully synched light chain existed). Shortly after reaching the last block, it crashed (I would expect to crash as soon as I launched it if it was an old chain related problem).
INFO [05-03|17:58:20] Imported new block headers count=384 elapsed=537.841ms number=3644031 hash=c0029a…308238 ignored=0 INFO [05-03|17:58:21] Imported new block headers count=79 elapsed=109.568ms number=3644110 hash=e83a3b…3fb255 ignored=0 INFO [05-03|17:58:33] Imported new block headers count=1 elapsed=13.929ms number=3644111 hash=ef5212…8568c2 ignored=0
... crash shortly (see below).
System information
Geth version:
geth version
1.6.0-facc47cb OS & Version: Linux Ubuntu 16.04 LTS 64 bit Commit hash : (ifdevelop
)Expected behaviour
Working flawlessly
Actual behaviour
INFO [05-03|18:25:12] Imported new block headers count=1 elapsed=9.539ms number=3644200 hash=0a5976…37813b ignored=0 panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x1c0 pc=0xb6152c]
Steps to reproduce the behaviour
Launch geth --syncmode light with an old light chain not synched for 2+ months
Backtrace
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x1c0 pc=0xb6152c]
goroutine 1082 [running]: github.com/ethereum/go-ethereum/les.(lightFetcher).checkAnnouncedHeaders(0xc4245c6a80, 0xc4214a1140, 0xc4245bacc8, 0x1, 0x1, 0xc4245bacc0, 0x1, 0x1, 0x500000000000000) /home/travis/gopath/src/github.com/ethereum/go-ethereum/les/fetcher.go:566 +0x17c github.com/ethereum/go-ethereum/les.(lightFetcher).checkKnownNode(0xc4245c6a80, 0xc4201c0c80, 0xc4296d50e0, 0xc4254db780) /home/travis/gopath/src/github.com/ethereum/go-ethereum/les/fetcher.go:651 +0x1fa github.com/ethereum/go-ethereum/les.(lightFetcher).announce(0xc4245c6a80, 0xc4201c0c80, 0xc42084ea80) /home/travis/gopath/src/github.com/ethereum/go-ethereum/les/fetcher.go:326 +0x7f1 github.com/ethereum/go-ethereum/les.(ProtocolManager).handleMsg(0xc420255680, 0xc4201c0c80, 0x0, 0x0) /home/travis/gopath/src/github.com/ethereum/go-ethereum/les/handler.go:489 +0x9c4 github.com/ethereum/go-ethereum/les.(ProtocolManager).handle(0xc420255680, 0xc4201c0c80, 0x0, 0x0) /home/travis/gopath/src/github.com/ethereum/go-ethereum/les/handler.go:428 +0x793 github.com/ethereum/go-ethereum/les.NewProtocolManager.func1(0xc4208a8690, 0x16a7ce0, 0xc420825570, 0x0, 0x0) /home/travis/gopath/src/github.com/ethereum/go-ethereum/les/handler.go:169 +0x1c6 github.com/ethereum/go-ethereum/p2p.(Peer).startProtocols.func1(0xc420825570, 0xc4208a8690) /home/travis/gopath/src/github.com/ethereum/go-ethereum/p2p/peer.go:301 +0x5d created by github.com/ethereum/go-ethereum/p2p.(*Peer).startProtocols /home/travis/gopath/src/github.com/ethereum/go-ethereum/p2p/peer.go:310 +0x24a