00:06:42 <hyc> btw, I had also restarted sync from scratch, using ethernet cable instead of wifi, and didn't hit this issue for at least 1M blocks
00:06:54 <hyc> so there was definitely a timing element
00:12:55 <moneromooo> 1M sounds similar to how much I had to wait before seeing it.
00:13:09 <moneromooo> Though I did the first 125k repeatedly.
00:28:47 <wfaressuissia[m]> after runtime debugging vtable is correct now
00:30:09 <wfaressuissia[m]> realized how to print content of boost::unordered_map , printed for all connections m_remote_address, turned out all of them ok
00:30:39 <moneromooo> But terminate is still called ?
00:30:53 <wfaressuissia[m]> let me share backtrace
00:31:20 <wfaressuissia[m]> any service to share online vimdiff ?
00:38:19 <wfaressuissia[m]> pasted to https://paste.dev.centos.org/view/raw/6dd8ff2f but it triggers some internal error
00:38:29 <wfaressuissia[m]> in their website
00:38:53 <hyc> try paste.debian.net
00:39:29 <wfaressuissia[m]> size limitted
00:39:31 <hyc> huh. gcc 10.2.0 segfaults while compiing the tree
00:39:40 <moneromooo> paste.ubuntu.com works for longer.
00:39:54 <wfaressuissia[m]> there is raw url for anonymous, ok for you ?
00:40:09 <moneromooo> I can save and edit.
01:00:13 <hyc> this run is looking good, still on ethernet. I'll switch back to wifi.
01:33:04 <hyc> heh. ok, had another mystery disconnect, but this time I had a kernel error msg, ethernet driver flaked.
01:33:12 <hyc> had to ifconfig down/up the interface to resume
01:34:37 <hyc> sometimes it's a mirale anything works at all
01:34:41 <hyc> miracle
01:41:20 <selsta> .merge+ 7269 7268
01:41:20 <xmr-pr> Added
02:13:17 <hyc> hmm. 2021-01-03 02:12:00.689 W Failed to commit a transaction to the db: File too large
02:13:31 <hyc> auto resize isn't triggering soon enough?
02:13:40 <hyc> 2021-01-03 02:12:00.6725621319217
02:13:57 <hyc> I HEIGHT 1227287, difficulty:
02:14:07 <hyc> 5621319217
02:18:27 <hyc> and looks like a segv in logger while stopping monerod https://paste.debian.net/1179498/
02:20:37 <hyc> yeah I'm stuck at height 1227327, auto resize not kicking in
02:25:05 <selsta> even after restarting?
02:25:51 <hyc> yep still no joy
02:29:47 <hyc> wiping it and starting again
02:31:52 <moneromooo> No logs of it ?
02:32:34 <hyc> I have the bitmonero.log but there's nothing useful or unusual in it
02:32:52 <hyc> no other error messages
02:50:03 <selsta> .merges
02:50:04 -xmr-pr- 7248 7261 7262 7263 7264 7268 7269 7271 7272
02:53:14 <selsta> vtnerd: please take a look at https://github.com/monero-project/monero/pull/7248 again. mooo implemented your suggestions
02:54:12 <moneromooo> (some)
03:04:51 <Mmmmmmmmmm> Why do the Mac and Windows CI checks fail?
03:11:01 <hyc> ... so, back on wifi. I guess the network speed actually does make a measurable difference. CPU use was around 100% on ethernet. back down in the 80% range on wifi.
03:44:09 <hyc> getting close. 1030640, no errors yet
04:04:31 <hyc> just blew past it. oh well. sync still going fine, no errors
09:37:56 <M5M400> just wanted to say that v0.17.1.8 is the first version since 0.17.x that survived 3 days without segfault
09:38:01 <M5M400> on node.supportxmr.com
09:38:29 <hyc> it has definitely not survived without segfault for me, doing sync from scratch
09:38:40 <hyc> but the recent patches seem to be behaving OK
09:39:02 <M5M400> weird. running it on 6 nodes and not a single issue since release
09:39:31 <M5M400> even using dns block list that is supposed to cause problems
09:39:58 <hyc> well, my VPS node is also running it fine, but that was just continuing its existing blockchain DB
09:40:42 <M5M400> ah, k. I didn't sync from scratch
09:42:05 <hyc> I'm now working under the assumption my SSD is flaking out
09:42:27 <hyc> which is a bit annoying, but the last time I used this system was like a year ago, and it had no problems back then
09:42:42 <hyc> still, SSDs have finite life spans
09:43:32 <sech1> SSD without a power for a year? It might loose some data
09:45:39 <hyc> yeah
09:45:50 <hyc> it appears to be corrupting data now
09:46:09 <hyc> well, I don't even know that yet. nothing in kernel logs.
09:46:25 <hyc> but I get some DB errors during sync
14:36:34 <hyc> definitely seems to be bad blocks on my SSD. Now every time monerod crashes I rename data.mdb so its sectors don't get reused.
14:36:45 <hyc> and the sync gets further when I restart it
14:54:07 <gingeropolous> aight im syncing from scratch across 7 different shitty ssds in raid
14:54:49 <gingeropolous> log 4 baby. gonna catch em all
14:54:54 <gingeropolous> of course its not debug. :(
14:55:00 <gingeropolous> well i'll do it again
14:55:02 <sech1> Is it RAID0?
14:56:01 <gingeropolous> yeah the one with no redundancy
15:04:54 <gingeropolous> well it might be the new raidz, i forget now
16:07:04 <ErCiccione[m]> I'm syncing a stagenet node that seems to be banning nodes. Sounds weird.
16:07:58 <ErCiccione[m]> 6 banned within a couple of hours
16:08:08 <moneromooo> Did you keep logs ?
16:10:11 <ErCiccione[m]> i did not.
16:10:33 <ErCiccione[m]> I'm giving it some proper settings now. i simply run it with monerod --stagenet
16:11:01 <selsta> I assume that’s the same false positives we have why syncing on main chain
16:38:58 <gingeropolous> hrm, sync got killed
16:40:10 <gingeropolous> guess i'll compile debug
16:40:29 <selsta> gingeropolous: which version
16:40:38 <gingeropolous> v0.17.1.8
16:40:49 <gingeropolous> syncing of of an exclusive local node
16:50:57 <selsta> gingeropolous: if you want to compile yourself, release-v0.17 + 7248 + 7262 + 7264 + 7266 + 7269 + 7272 will be v0.17.1.9 most likely
16:51:55 <gingeropolous> ok, so checkout v0.17.1.8 and these PRs?
16:53:22 <gingeropolous> 7266 gave me a conflict
16:54:12 <gingeropolous> using this approach: git pull origin pull/7266/head
16:54:12 <gingeropolous>  , and doing them in sequence adding each PR starting at 7248
16:54:13 <selsta> release-v0.17 + 7248 + 7262 + 7264 + 7267 + 7269 + 7272 will be v0.17.1.9 most likely
16:54:21 <selsta> yea had a typo
16:54:28 <selsta> git checkout release-v0.17
16:54:39 <selsta> git pull origin pull/7248/head
16:54:41 <selsta> and the same for others
16:54:45 <gingeropolous> resolve my current index my ass. ima nuke u folder
16:57:21 <sech1> rm -rf monero
17:07:45 <gingeropolous> thanks for your patience selsta
17:44:55 <gingeropolous> hrm, i added --add-exclusive-node yet i still have 5(out)+8(in)
17:45:17 <gingeropolous> i wonder if running in gdb made parsing those commands odd. though it did goto the data directory i specified
17:45:57 <gingeropolous> did new peerlist stuff cause an override of exclusive node startup flags?
17:46:26 <iDunk> gdb --args /path/to/monerod --add-exclusive-node a.b.c.d
19:23:23 <gingeropolous> ah, i did gdb ./monerod , then ran r --(insert flags)
20:51:13 <sgp_> https://github.com/monero-project/research-lab/issues/79
22:16:08 <mj-xmr> Just completed unity build for both core tests and unit tests @ 7217
22:16:14 <mj-xmr> Good night