Invalid memory address or nil pointer dereference on Raspberry Pi

I’m running an Algorand Node (Test Net) on Raspberry Pi 3 (B) and after a while I got the following error:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x751442e4]

goroutine 2804 [running]:
runtime/internal/atomic.goStore64(0x44f09e5c, 0x0, 0x0)
/usr/local/go/src/runtime/internal/atomic/atomic_arm.go:140 +0x1c
github_com/algorand/go-algorand/data/pools.(*TransactionPool)_computeFeePerByte(0x44f09e00, 0x0, 0x0)
/go/src/github_com/algorand/go-algorand/data/pools/transactionPool.go:280 +0xcc
github_com/algorand/go-algorand/data/pools.(*TransactionPool).checkSufficientFee(0x44f09e00, 0x45ed6000, 0x1, 0x2, 0x76f81318, 0x3b9aca00)
/go/src/github_com/algorand/go-algorand/data/pools/transactionPool.go:289 +0x24
github_com/algorand/go-algorand/data/pools.(*TransactionPool).ingest(0x44f09e00, 0x45ed6000, 0x1, 0x2, 0x485afc20, 0x1, 0x1, 0x0, 0x0, 0x0, …)
/go/src/github_com/algorand/go-algorand/data/pools/transactionPool.go:365 +0x250
github_com/algorand/go-algorand/data/pools.(*TransactionPool).Remember(0x44f09e00, 0x45ed6000, 0x1, 0x2, 0x485afc20, 0x1, 0x1, 0x0, 0x0)
/go/src/github_com/algorand/go-algorand/data/pools/transactionPool.go:401 +0xcc
github_com/algorand/go-algorand/data.(*TxHandler).postprocessCheckedTxn(0x44ec2000, 0x47602660)
/go/src/github_com/algorand/go-algorand/data/txHandler.go:191 +0x160
/go/src/github_com/algorand/go-algorand/data/txHandler.go:164 +0x454
created by github_com/algorand/go-algorand/data.(*TxHandler).Start
/go/src/github_com/algorand/go-algorand/data/txHandler.go:103 +0x120

Status command:

Last committed block: 8893136
Time since last block: 2.2s
Sync Time: 0.0s
Last consensus protocol: […]
Next consensus protocol: […]
Round for next consensus protocol: 8893137
Next consensus protocol supported: true
Last Catchpoint:
Genesis ID: testnet-v1.0
Cannot contact Algorand node: Get […] dial tcp connect: connection refused.

How I can fix it?


1 Like


The last betanet release seems to include a fix for this issue (BetaNet Update: Version 2.1.4 " * Fix for ARM32 memory panic")

I’d suggest that you’ll wait for the official release to mainnet of these changes. Given that it’s not a protocol upgrade, the delay is usually not substantial.

Other solution that might work for you is to use the betanet binaries against the mainnet data directory.

As a last resort, in case you see none of these works, you can aways try and build from source on master. ( but I generally don’t recommend that since you might not be able to get proper support if this isn’t an official release branch )

1 Like

The v2.1.4-stable release is now available, so I would recommend trying that and seeing if this problem goes away.

Up and Running!