Closed Githrasher closed 1 year ago
Can you pass -v
to increase verbosity to get the debug logs? Also which system specification do you have? capacity overflow
normally hints to an out of memory situation
Можете ли вы перейти
-v
к увеличению детализации, чтобы получить журналы отладки? И какая спецификация системы у вас есть?capacity overflow
обычно намекает на ситуацию нехватки памяти
System AMD Ryzen 9 3900 , Win10 pro, RAM 16Gb Hdd 1Tb
rustc 1.70.0 (90c541806 2023-05-31)
cargo 1.70.0 (ec8a8a0ca 2023-04-25)
1.70-x86_64-pc-windows-msvc unchanged - rustc 1.70.0 (90c541806 2023-05-31)
Maybe I built it wrong. Build without errors. Could you give already built rusty-blockparser
16GB of RAM should be fine at this point. I'm not to sure how Windows works in this regard, but can it be that C:\Temp is mapped into RAM (similar to tempfs on linux) and the RAM will fill up very quickly because the program is started in C:\Temp and also the dump path is also set to this.
Can you try to execute this somewhere else like C:\Users... (also setting a different dump path) and monitor the memory usage when starting it?
Also make sure to build the executable with cargo build --release
.
So I built the project cargo build --release
Could you give already built rusty-blockparser
I think the binary works fine, however I cannot reproduce this on linux and have currently no windows instance to test on. Please check and verify the RAM usage with the task manager or similar things to rule out OOM errors.
It might also be worth to test another command like simplestats
which doesn't allocate a lot of memory upfront or versions 0.9.0 and 0.10.0 to narrow it down a bit.
Could you give already built rusty-blockparser
I think the binary works fine, however I cannot reproduce this on linux and have currently no windows instance to test on. Please check and verify the RAM usage with the task manager or similar things to rule out OOM errors.
It might also be worth to test another command like
simplestats
which doesn't allocate a lot of memory upfront or versions 0.9.0 and 0.10.0 to narrow it down a bit.
I tried it on a 32GB PC too.
Hello. I tried this today in VirtualBox Ubuntu 18 What am I doing wrong?
This stacktrace is very helpful and brings us closer to the solution. It seems most likely that the blockchain data is corrupt, can you resync (or verify/repair it in any way)?.
The problem is that the parser tries to read some variable length integer in read_tx
that have a special encoding, if this data is corrupt the parser tries to allocate an unreasonable amount of memory and bails out, which is most likely the case here.
Any update on this one? Did it work after resyncing the chain?
Closing this, feel free to reopen if a resync doesn't help
I built the latest version 0.11.0 . And I get this error "capacity overflow" Could you help me fix this.