sasha

Gonna try to reproduce this issue (git hash `b2e4c0562c3139092ae791339070093c75df4084`, which should have #6172 merged in), thanks!

It still OOMs, unfortunately. Tomorrow I'll see if I can get `heaptrack` compiled from source and working (the version on debian 11 doesn't seem to parse the DWARF information in...

Here's some info from heaptrack -- unfortunately it's not quite clear to me exactly where the `unsigned long` allocations are happening.

Ok (and of course I consider this after closing the heaptrack visualizer program, which took 6 hours to load), i think that the `unsigned long` allocations are downstream of the...

If we have `1561625892` bytes consumed by the mystery `unsigned long` allocation after `15 hours 51 minutes 25 seconds`, we're at block height `905243` by then, this means that the...

The most viable hypothesis I currently have is that the Equihash solutions *for every block* are being kept in memory (inside `CBlockHeader` at least) and 1344 bytes * a million...

@daira corrects me on slack, it's not `CBlockHeader` but `CBlockIndex`, i was confused because `CBlockHeader` showed up as well but `CBlockIndex::CBlockIndex(CBlockHeader const&)` means we're creating a `CBlockIndex` (and doing it...

Renamed the issue since we know what's causing it. The fix i have in mind (making `nSolution` a zero-length vector after proof of work is checked) is nontrivial since `CBlockIndex::GetBlockHeader()`...

Here's where `GetBlockHeader` is called in the codebase: ``` Searching 1569 files for "GetBlockHeader" (case sensitive) /Users/sasha_work/remote_vm_repos/zcash/src/chain.h: 387 } 388 389: CBlockHeader GetBlockHeader() const 390 { 391 CBlockHeader block; /Users/sasha_work/remote_vm_repos/zcash/src/main.cpp:...

Here's where `GetBlockHash` is called in the codebase: ``` Searching 1210 files for "GetBlockHash" (case sensitive) /Users/sasha_work/remote_vm_repos/zcash/src/chain.cpp: 30 pindex = Tip(); 31 while (pindex) { 32: vHave.push_back(pindex->GetBlockHash()); 33 // Stop...