-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed handling transactions when using multiple sentries on BSC #3799
Comments
I've conducted 1 hour testing with 8 sentries and no errors were registered. |
thank you |
After leaving the node for some time with the same setup I have experienced a new crash: panic: interface conversion: interface {} is nil, not *simplelru.entry goroutine 206 [running]: Should I open a new Issue? |
Once again there is a similar panic after running node for 2-3 hours. panic: interface conversion: interface {} is nil, not *simplelru.entry goroutine 209 [running]: |
8 more hours of testing - no errors. Seems that this error is not that easy to reproduce |
don't know the reason yet |
One more (no pressure, just want to provide as more info for debugging as possible) panic: interface conversion: interface {} is nil, not *simplelru.entry goroutine 229 [running]: |
@limhyesook do you run external pool or inside erigon? |
Everything is inside except rpcdaemon and sentries. |
System information
Erigon version: 2022.99.99-dev-4e23187c
OS & Version: Ubuntu
Commit hash : 930d662
Expected behaviour
Erigon is run with multiple sentries and works without errors
Actual behaviour
When launched with remote sentries (tested with 4 sentries on remote servers) errors about handling transactions are intermittently reported in master's logs. Example:
[WARN] [03-31|06:36:02.301] [txpool.fetch] Handling incoming message msg=TRANSACTIONS_66 err="runtime error: invalid memory address or nil pointer dereference, trace: [fetch.go:206 panic.go:1047 panic.go:221 signal_unix.go:735 cursor.go:67 cursor.go:67 txn.go:611 kv_mdbx.go:1042 kv_mdbx.go:1029 kv_mdbx.go:1033 kv_mdbx.go:894 kv_mdbx.go:929 pool.go:592 fetch.go:298 types.go:391 packets.go:179 fetch.go:315 fetch.go:88 fetch.go:314 fetch.go:185 fetch.go:144 fetch.go:101 asm_amd64.s:1581], rlp: f903a2f9018e820211850165a0bc008303a01d9410ed43c718714eb63d5aa57b78b54704e256024e80b9012438ed1739000000000000000000000000000000000000000000000000d02ab486cedc0000000000000000000000000000000000000000000000000000023d11eabe65aaf800000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000eecc51225befcfa56387091c80bf517391d4721b00000000000000000000000000000000000000000000000000000000624534500000000000000000000000000000000000000000000000000000000000000003000000000000000000000000e9e7cea3dedca5984780bafc599bd69add087d5600000000000000000000000055d398326f99059ff775485246999027b3197955000000000000000000000000f2572fdacf09bfae08ff7d35423870b5a8ac26b78194a0ae29ed213e2a70b30c49f4ffd25a16f442f0e69dfcbed2242249796e97fcc6a3a0786e95c72d6446b64afa43dffb42ec615628bbe8e276eed66fa36fa4873bd8e8f9020e820b7c850165a0bc008327798a94468fc54b82b590d1698251d2bce1a9f91c43f04280b901a4d36785290000000000000000000000000000000000000000000000000002cb4178000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000050000000000000000000026f716b9a82891338f9ba80e2d6970fdda79d1eb0dae00000000000000000000271055d398326f99059ff775485246999027b31979550000000000000000000026f2126e06540456d60a200b28181581057a01a561a5000000000000000000002710f2572fdacf09bfae08ff7d35423870b5a8ac26b70000000000000000000026f72f82c93b5eb21f57e46734f798a582594b09a71900000000000000000000271055d398326f99059ff775485246999027b31979550000000000000000000026f7e60f8896d30031cd8aec3badd6ecb1dcb6bdf64b0000000000000000000027101977aee8ee48244ad473815920bcdfe3295c11d10000000000000000000026f70ec3033ef0193fb8922a100c35e57a2b98c175c1000000000000000000002710bb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c8193a029395ec73d650569a571338ccdca2156f7dcd9ab8280b13e424032d087ad1c55a04852341aaf7056870b9880f825ae1339dddebef15bf2b8f15a5cdc86ef57cc09"
I have tested this with different number of sentries (1 to 8 with 100 peers each) and there seems to be a correlation between number of sentries and frequency of errors. On 8 sentries I've experienced node crash as well.
Steps to reproduce the behaviour
Run remote sentries on 4-8 remote servers and run Erigon connecting to them.
Backtrace
The text was updated successfully, but these errors were encountered: