This happened to me on the master branch commit 5184b4483f which was slated to become our next release. This bug may be caused by weirdness in this wallet, which seems to have almost 4000 expired transactions which attempt to get relayed occasionally and generate a log line of :
We need to figure out if this is a common issue or if it only affects "weird wallets" with lots of expired transactions.
After running for a while (not sure how long) hushd coredumps with SilentDragon connected to a wallet of about 150MB:
```
GetNextWorkRequired: nbits=486785586
Unexpected error 9 on netlink descriptor 27.
```
Last few lines of debug.log :
```
2023-02-12 06:02:55 getchaintxstats: blockcount = 34560
2023-02-12 06:02:55 getchaintxstats: pindexPast.height = 1219818, pindex.height = 1254378
2023-02-12 06:02:55 getchaintxstats: pindexPast.nChainPayments = 0, pindex.nChainPayments = 841305
2023-02-12 06:02:55 TLS: ERROR: SSL_read Please supply a buffer for error string
```
This happened to me on the master branch commit `5184b4483f` which was slated to become our next release. This bug may be caused by weirdness in this wallet, which seems to have almost 4000 expired transactions which attempt to get relayed occasionally and generate a log line of :
```
ResendWalletTransactionsBefore: ignoring expired tx ...
```
Another machine did a full sync from scratch with the same code and did not hit this error. It had an empty wallet and didn't have SD connected to it.
This error is generated deep in glibc, not our code, and seems to be related to race condition bugs in multi-threaded code that does networking : https://sourceware.org/bugzilla/show_bug.cgi?id=12926#c17
curl has run into a similar issue: https://github.com/curl/curl/issues/3386#issuecomment-455840319
We need to figure out if this is a common issue or if it only affects "weird wallets" with lots of expired transactions.
To test for this bug: Use the latest master branch of code and testing at least these 2 scenarios would help:
Sync from scratch with the new code, with no pre-existing ~/.hush/HUSH3 directory
Leave hushd running overnight (many hours) connected to SD, with a non-empty wallet
If anybody else can trigger this error, it's likely that average users will hit it too. Please also try to get a backtrace from any coredumps.
To test for this bug: Use the latest master branch of code and testing at least these 2 scenarios would help:
1) Sync from scratch with the new code, with no pre-existing ~/.hush/HUSH3 directory
2) Leave hushd running overnight (many hours) connected to SD, with a non-empty wallet
If anybody else can trigger this error, it's likely that average users will hit it too. Please also try to get a backtrace from any coredumps.
After running for a while (not sure how long) hushd coredumps with SilentDragon connected to a wallet of about 150MB:
Last few lines of debug.log :
This happened to me on the master branch commit
5184b4483fwhich was slated to become our next release. This bug may be caused by weirdness in this wallet, which seems to have almost 4000 expired transactions which attempt to get relayed occasionally and generate a log line of :Another machine did a full sync from scratch with the same code and did not hit this error. It had an empty wallet and didn't have SD connected to it.
This error is generated deep in glibc, not our code, and seems to be related to race condition bugs in multi-threaded code that does networking : https://sourceware.org/bugzilla/show_bug.cgi?id=12926#c17
curl has run into a similar issue: https://github.com/curl/curl/issues/3386#issuecomment-455840319
We need to figure out if this is a common issue or if it only affects "weird wallets" with lots of expired transactions.
To test for this bug: Use the latest master branch of code and testing at least these 2 scenarios would help:
If anybody else can trigger this error, it's likely that average users will hit it too. Please also try to get a backtrace from any coredumps.
Haven't seen this error again, has anybody else seen this error?