05:21:10 selsta moneromooo wfaressuissia I got this crash again: https://paste.debian.net/hidden/6b06edc2/ 05:21:54 anything else I can do in gdb before I kill the process? I'll wait for a few hours. 05:23:00 it seems to be the race fixed in https://github.com/monero-project/monero/pull/7873 05:24:21 I think you can close it and recompile latest release-v0.17 05:24:59 still don't know why it gets triggered so frequently on your machine 05:27:32 Now I need to understand how the fix works 05:28:02 I mean, it removed "std::vector fluff_txs;" alltogether, but where it was used? 05:28:38 btw you can use gcore inside gdb to save the core file so that you don't have to keep it open 05:28:57 though don't remember the exact command 05:30:40 so the fix moved "fluff_txs" from p2p connection to a separate struct, ok 05:33:02 it crashes so often probably because of slow HDD + purged node. It was a full node before but it didn't crash. 05:33:25 maybe also because p2pool connects to it and ZMQ is activated 05:34:53 the difference with my other stable node is HDD/SSD and purged/full 05:38:49 building latest release-v0.17, I'll run it under gdb for a few days too 05:39:16 to make sure that the fix actually fixes the crash. My server is a perfect "Canary" :D 08:25:23 `node_server: add race condition demo` all these demos are reproducing with almost 100% probability fixed problem for debug/release build 08:26:05 so anyone can run that demo under gdb without fix to know what was the problem 09:44:12 17.3 is getting prepared, i assume we're getting it 1st of November, right? 11:59:59 luigi1111: merges today? 12:58:21 yes 17:56:04 2021-10-25 15:49:22.034 I SYNCHRONIZED OK 17:56:04 free(): corrupted unsorted chunks 17:56:04 Aborted 17:56:12 just had a long-ish running Linux node die 17:56:26 moneromooo: something you're aware of or should I see if it dumped? 17:57:41 `free(): corrupted unsorted chunks` very interesting, any info ? 17:57:50 this is on v0.17.2.3-release btw 17:58:13 anything in dmesg /journalctl ? 17:58:50 it was running in a screen session, so nothing in journalctl 17:58:58 dmesg looks normal too 18:00:07 how screen may hide abnormally terminated processes from journalctl ? gdb - yes, screen/tmux - likely no 18:05:19 "dmesg looks normal too" it's probably normal, so no info without coredump then 18:06:29 That's a bad bug and needs a fix. 18:39:04 bah - no coredumps enabled 18:39:31 wfaressuissia: sorry I saw journalctl and read systemd, my brain is on the fritz today 18:45:09 journalctl looks clean too 18:45:11 I've turned dumps on 18:45:15 will see if it happens again 21:44:20 Fingerprint is still 81AC 591F E9C4 B65C 5806 AFC3 F0AF 4D46 2A0B DF92 right? 21:45:39 Part of your message is missing (the part where you say what that fingerprint is meant be for). 23:52:44 .merges 23:52:44 -xmr-pr- 7995 7996 8002 8003 8004 8006 8007 8011 8018 8019 8022