panic: runtime error: invalid memory address or nil pointer dereference #18388
Comments
|
Could you try out #18436 if it fixes your issue? |
|
Hi. I also get this error. Here's my launch line. `INFO [02-04|19:08:30.845] Maximum peer count ETH=25 LES=0 total=25 goroutine 11159 [running]: This problem started from 2019-01-31 |
|
@Lvovich2018 Before even diving into this crash, please immediately close your node's RPC port from the internet. Your logs are full of failed unlock attempts, pointing to someone remotely trying to brute force your password: |
|
OK, closed. But the error remained. `INFO [02-04|19:44:34.464] Maximum peer count ETH=25 LES=0 total=25 goroutine 305 [running]: |
|
I have the same error trying to re-synchronize a node. Only works deleting database and downloading it all again. |
Thank you for your advice. Unfortunately, I can't do that. And there is no guarantee that it will help. |
|
Any recommendations on my problem? |
|
`INFO [02-05|09:19:50.099] Maximum peer count ETH=25 LES=0 total=25 goroutine 508 [running]: What am I to do? |
|
The original report has been fixed. The report by @Lvovich2018 is not fixed, and is a bit odd. var known bool
switch d.mode {
case FullSync:
known = d.blockchain.HasBlock(h, n)
case FastSync:
known = d.blockchain.HasFastBlock(h, n)
default:
known = d.lightchain.HasHeader(h, n)
}
if !known {
end = check
break
}
header := d.lightchain.GetHeaderByHash(h) // Independent of sync mode, header surely existsIt fails at the last line. @karalabe what's the reasoning behind that comment -- the chain is started in fullsync mode, it seems that the assumption that the lightchain has the header hash is not true. Could it be that the lightchain only has the canon blocks? |
|
The odd thing in this code segment is that We need to figure out what could have caused the fast sync head block to be present in the database, but it's number mapping to be missing. Not sure yet. |
|
Looking at our data access methods, it's again a bit weird: // WriteHeader stores a block header into the database and also stores the hash-
// to-number mapping.
func WriteHeader(db DatabaseWriter, header *types.Header) {
// Write the hash -> number mapping
var (
hash = header.Hash()
number = header.Number.Uint64()
encoded = encodeBlockNumber(number)
)
key := headerNumberKey(hash)
if err := db.Put(key, encoded); err != nil {
log.Crit("Failed to store hash to number mapping", "err", err)
}
// Write the encoded header
data, err := rlp.EncodeToBytes(header)
if err != nil {
log.Crit("Failed to RLP encode header", "err", err)
}
key = headerKey(number, hash)
if err := db.Put(key, data); err != nil {
log.Crit("Failed to store header", "err", err)
}
}
// DeleteHeader removes all block header data associated with a hash.
func DeleteHeader(db DatabaseDeleter, hash common.Hash, number uint64) {
if err := db.Delete(headerKey(number, hash)); err != nil {
log.Crit("Failed to delete header", "err", err)
}
if err := db.Delete(headerNumberKey(hash)); err != nil {
log.Crit("Failed to delete hash to number mapping", "err", err)
}
}I.e. We first write the |
|
@Lvovich2018 Could you please run with |
@karalabe, sorry, I can't do that right now. I only found a solution to my problem an hour ago. Helped downgrade geth on 1.8.19. Now the blocks are synchronizing, I can't stop the process. If on new versions this problem appears, I will surely insert logging. Thanks for your help. |
|
Since original report is fixed, let's move over to #18994 |
and others
Hi there,
I have a topology consisting of 48 docker containers. Each container runs its own geth node. (The docker containers are build from my custom docker image -> see below). Each geth node is a miner. After I create many transactions and ca 1500 blocks are generated. One geth node reports the runtime error mentioned below.
My dockerfile:
Genesis.json:
Steps to reproduce the behaviour
docker run -it -d -p ${enodePortNr}:30303 --network="eth" --name ${client.name}_bc --net-alias=${client.name}_bc mygeth --rpc --rpcaddr 0.0.0.0 --rpcport 8545 --datadir /data --syncmode "fast" --cache "1024" --rpcapi="db,eth,net,web3,personal,web3" --txpool.pricelimit "0" --miner.gasprice "0" --maxpeers "80" --nodiscover --verbosity 4'Backtrace
The text was updated successfully, but these errors were encountered: