mx4
commented
10 years ago Ah, cool. I added this ASSERT some time back to catch an instance of a bug I've been tracking for some time. You can basically get rid of the problem by resync'ing your txdb/headers:
./bitc -z
.. and things will/should go smoothly afterwards.
Btw, were you running the top-of-trunk from bitc? IOW, when did you last sync-up your tree?
If that's ok with you, I'd like to debug this a bit and would like to confirm that you're seeing the same issue I was trying to track down when I added this ASSERT. I will ideally need the bitc binary+core dump (beware of the privacy implication, so feel free to say no).
The problem here is that it's possible that the last block we were sync'd at when we last shut down is now an orphan. So when it's time to compute from where we need to refresh the txdb, we find a height of 0 because that block is orphaned..
I know what needs to be done to address this issue (walk backwards from that orphan until we hit the current best chain and use this junction node as a valid sync point), but it's a bit annoying to code (lazy me), so if that proves to be the issue that'll be a good incentive to finally find the time to fixing this.
combwattle
Hi all,
I have been running bitc smoothly until I sent 0.001 btc to the default address assigned by bitc. Afterward, bitc quits automatically while trying to connect to peers showing the following message. Has anybody else seen a similar issue?
ASSERT failed at src/block-store.c:blockstore_get_highest:178 PANIC: Expression 'height1 > 0' not TRUE. Aborted (core dumped)
I tried to find a relevant section in the code, and it seems like lastHashStore is the immediate cause of the problem. Since peerGroup determines lastHashStore, I suspect that peerGroup is not being set up properly.
peergroup_get_lastblk(btc->peerGroup, &lastHashStore); blockstore_get_highest(bs, &walletHash, &lastHashStore, &startHash); ... height0 = blockstore_get_block_height(bs, hash0); height1 = blockstore_get_block_height(bs, hash1); ASSERT(height0 > 0);// PANIC