Bug: OversizedVectorAllocation during initial synch (0.9.9) #806
Comments
amosgroth
changed the title
|
It seems that electrs fails to parse Could you please try to retrieve it using: and attach the resulting |
|
Hi Roman, Thx for your support. Pls find the file attached... |
|
Would there be the possibility to redownload and integrate the corrupted block with BTC Core in order to fix my problem with Electrum? (to prevent synching the whole blockchain from scratch) |
|
It seems that your node doesn't have the block available (the content of the |
|
BTW, are the any errors in bitcoind logs? |
That's strange. My node says it's 100% synched and didn't complain while synching. I can also connect wallets through BTC Core. The log seems to be fine, One additional info that might be relevant for this is that I had a backup copy from the Bitcoin data directories (blocks/chainstate/indexes) from a few months ago - I used that to save time and bandwidth for synching... |
I searched the whole log file at ~/umbrel/app-data/bitcoin/data/bitcoin/debug.log:
Only mentioned by Electrum... |
|
Could you please look for //// in src/rpc/blockchain.cpp
static CBlock GetBlockChecked(BlockManager& blockman, const CBlockIndex* pblockindex) EXCLUSIVE_LOCKS_REQUIRED(::cs_main)
{
AssertLockHeld(::cs_main);
CBlock block;
if (blockman.IsBlockPruned(pblockindex)) {
throw JSONRPCError(RPC_MISC_ERROR, "Block not available (pruned data)");
}
if (!ReadBlockFromDisk(block, pblockindex, Params().GetConsensus())) {
// Block not found on disk. This could be because we have the block
// header in our index but not yet have the block or did not accept the
// block.
throw JSONRPCError(RPC_MISC_ERROR, "Block not found on disk");
}
return block;
}
//// in src/node/blockstorage.cpp
bool ReadBlockFromDisk(CBlock& block, const FlatFilePos& pos, const Consensus::Params& consensusParams)
{
block.SetNull();
// Open history file to read
CAutoFile filein(OpenBlockFile(pos, true), SER_DISK, CLIENT_VERSION);
if (filein.IsNull()) {
return error("ReadBlockFromDisk: OpenBlockFile failed for %s", pos.ToString());
}
// Read block
try {
filein >> block;
} catch (const std::exception& e) {
return error("%s: Deserialize or I/O error - %s at %s", __func__, e.what(), pos.ToString());
}
// Check the header
if (!CheckProofOfWork(block.GetHash(), block.nBits, consensusParams)) {
return error("ReadBlockFromDisk: Errors in block header at %s", pos.ToString());
}
// Signet only: check block solution
if (consensusParams.signet_blocks && !CheckSignetBlockSolution(block, consensusParams)) {
return error("ReadBlockFromDisk: Errors in block solution at %s", pos.ToString());
}
return true;
}
//// in src/util/system.h
template<typename... Args>
bool error(const char* fmt, const Args&... args)
{
LogPrintf("ERROR: %s\n", tfm::format(fmt, args...));
return false;
} |
Maybe you can try: |
|
Downloaded the whole log file, searched for string "error:". First error I found was this:
I would guess this is irrelevant and has to do with the shutdown of the server because I found this similar error 3 times in the logs and it got thrown every time the node was shutting down. More interesting, I guess:
This error was thrown once and after that the log is free from errors... |
No luck: |
is indeed the relevant issue - looks like the block is corrupted on disk :( |
Oh, boy. :( A few questions regarding that:
|
Not sure currently it's possible to force re-downloading a specific block :(
If the corruption happened after bitcoind sync was over, it's hard to detect (since most of the queries do not involve historical blocks) except of re-reading the blocks (as we did above using
electrs needs access to all historical blocks to build its index.
Maybe you could try https://github.com/bwt-dev/bwt? CC: @shesek |
|
I don't think BWT will help here since it will need to rescan whole chain and will hit the same bug. The only solution here is to run Core with |
|
I hope it can work if we rescan only the last N blocks - see https://github.com/bwt-dev/bwt#pruning |
Yeah, wouldn't help me. If it was only for that I would just use a public Electrum server and Sparrow. But the app I had installed on Umbrel and not have the recovery words from (ItchySats) derives it's wallet from the Umbrel seed/wallet (which I have and recovered so far with BTC Core and LND). Since ItchySats needs Electrum Server, I am kind of in a trap. I know I am stupid, so telling me so wouldn't help anyone. ;) |
|
Thanks so much for your support and time anyway! If you have more ideas to share, let me know! Otherwise I will be sitting in the library tomorrow, trying to resync. :) |
|
Just wishing you good luck that it's not caused by HW failure. RPis are not very reliable either. :( |
|
Hello, I have a similar issue with electrs 0.9.10... With a different block : But while reading answers from romanz, my case is a bit different cause I can actually find the block from my bitcoin node (here the file is attached). |
|
It should be resolved in electrs 0.9.10 - could you please check the logs for the version you are running? Line 346 in faf1f07 |
|
Thank you very much for your answer ! I see this in the log of the service, while starting it: Is there another way of printing the logs ? It seems to be 0.9.1 running. Thank you |
|
Please upgrade to the latest release (0.9.10). You can also check the version by running: |
|
Thank you... Just did a stupid mistake mixing up beetwen v0.9.1 and v0.9.10, last time I upgraded, sorry 😅 Thank you for your answers and great work 👍 |
|
No problem, happy to help :) |
|
@amosgroth I am closing this issue for now, please reopen if the corruption reproduces. |
Describe the bug
Fresh Umbrel installation, fully synched Bitcoin Core, freshly installed Electrum fails and stops to synch:
I have tried this for the 3rd time now (un- and reinstalled Electrum, deleted all files in between, restarted synching). It seems it's always giving me the same error and it always stops at the same block height or same synching percentage (72%).
Electrs version
0.9.9
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Electrum Server synchs to 100% and doesn't stop in between, not being able to finish.
Configuration
The text was updated successfully, but these errors were encountered: