Apparently (on 64-bit systems), an average CBlock takes up about 8 times as much space as its serialized form. This results in high memory usage for all orphan blocks that are kept. Change this to retain them in serialized form instead.
Tested by doing a (partial) sync under valgrind, which involved processing orphans.
My client appears to be stuck at block 202978 on the mainnet chain For some reason I’m receiving the entire chain starting from 0000000000000062e33609a6653b870f76f3f61e6f0aa3d9100ad12d78926a79 (#241041) to #241869 as ORPHAN BLOCK Could of course be unrelated to this pull and simply a case of bad peers.
Oh… and it’s already syncing again :)
(still lots and lots of orphans though, if you’re interested in the debug.log, it’s here http://download.visucore.com/bitcoin/debug-3516.log.bz2)
No, receiving orphans is very expected and one of the reason why I’m working on headers-first.
The problem is that any peer that announces some blocks, we ask for it, and if it’s something whose parent we don’t know, we ask for the parents - starting a pretty much full sync process from this peer, even if we were already syncing from another before. The problem is just that if you’re syncing from two peers at once, some ranges of blocks are bound to be downloaded in incorrect order.
It’s certainly possible to improve this, and try to prevent starting a second sync from another peer if another is ongoing, but this sounds hard to do right and guarantee to deal well with all weird edge cases that can arise.
