search

monero-project / monero

Monero: the secure, private, untraceable cryptocurrency
https://getmonero.org
Other
8.77k stars 3.07k forks source link

monerod crashes #8881

Open paboum opened 1 year ago

paboum commented 1 year ago

[ 894.353747] traps: monerod[7719] general protection fault ip:559cb6f3a0b4 sp:7edecbffc7c8 error:0 in monerod[559cb6800000+1056000]

Seriously, what level of programming is this?

selsta commented 1 year ago

Which operating system? Which monerod version? Did you self compile it, install from package manager or use release binaries? Can you consistently reproduce the crash? What was monerod currently doing? What is your config?

paboum commented 1 year ago
  1. gentoo linux, perfectly stable and up-to-date
  2. Monero 'Fluorine Fermi' (v0.18.2.2-release)
  3. release binaries (however after I got tired of it, found out there is an ebuild in guru repository, installed it but haven't got the time and good will to retry it, after all release builds should be stable too
  4. yes, probably runs out of memory (I only have 128 GB) or just finds out the blockchain db is broken (see no. 7 below)
  5. just starting it after doing a fresh sync with ./extras/monero-blockchain-import --dangerous-unverified-import=1 --batch-size=200000 --input-file=blockchain.raw
  6. dunno the config, whatever the gui ran it with, in monero-core.conf there is daemonFlags=
  7. I tried like 3 times to run the full sync. It immediately increases the HDD usage to unbearable level, the load average goes up to 130.0 !! (even though I only have 24 cores) and makes the system unusable, can't even kill the damn thing without making a zombie out of it. Maybe got something to do that my non-ssd (but still modern and expensive) hdd drive is fully encrypted (and not with stock AES) and my kernel ONLY uses BFQ I/O scheduler and allows cgroups. Didn't want to mess with that so finally I managed to use the https://downloads.getmonero.org/blockchain.raw file without verification (as described in no. 5), it loads up in 10 hours or so, but then it STILL fails to use daemon effectively as it simply crashes. I cannot now tell you (didn't keep operations log) if my db file was corrupted by me resetting the machine by power cycle or SysRq reset, but then...
  8. The c++ application should NEVER crash, it means your code is insecure by the very least. Just run statical analysis tools to find all memleaks, uninitialised variable tests and other stuff, before you want to take on the world, thanks, bye. It didn't leave any call stack, debug logs or whatever useful other than kernel alert, so I'm not attaching. Deleted all thas large files from my OS and moved on, won't investigate further until I really have too much time. Maybe rewrite it to golang, IDK
paboum commented 1 year ago

Oh, and one more thing, since this is a release build, you young'uns should be just able to translate this monerod[559cb6800000+1056000] into the exact place in the code and think about what execution flow could cause crash there. As you can see, I've already given you more information than you need to fix this.

hinto-janai commented 1 year ago

This was fun to read.

Gingeropolous commented 11 months ago

dunno dude. I got 136 day uptime on my seed node.