[05:39:41] @mxaddict Are you here? [05:41:45] sda6@sda6-Z68X-UD4-B3:~/gitcola/navcoin-core/depends$ make -j8 Preprocessing libevent... autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf --force configure.ac:129: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are [05:41:46] legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 funcs.mk:251: recipe for target '/home/sda6/gitcola/navcoin-core/depends/work/build/x86_64-pc-linux-gnu/libevent/2.1.8-stable-dcc13e8b072/.stamp_preprocessed' failed make: *** [/home/sda6/gitcola/navcoin-core/depends/work/build/x86_64-pc-linux-gnu/libevent/2.1.8-stable-dcc13e8b072/.stamp_preprocessed] Error 1 [05:41:46] sda6@sda6-Z68X-UD4-B3:~/gitcola/navcoin-core/depends$ [07:39:48] @aguycalled i just woke up, haven't checked yet. [07:41:58] @roast you have build-essential installed? [08:15:37] @aguycalled @prole I could not replicate the issue that I experienced yesterday [08:15:42] I'll try again [08:16:07] Can you guys also run full sync with the patch that @aguycalled sent? [08:16:17] Maybe someone else can replicate it. [08:23:47] yes im doing and checking the code [08:30:43] The new sync I did last night did not fail [08:31:00] I've started a new one a few minutes ago [08:31:14] Do you think it's possibly a network issue? [08:31:30] That was the only thing that was different from yesterday's sync [08:31:49] My laptop got disconnected from WAN for a few minutes [08:38:59] i dont think its network related. anyway it should be resistant to those issues and sync flawlessly. [08:41:06] ACK [08:41:09] Will keep trying [09:33:39] which branch or pr? [09:33:47] im still reindexing #539 [09:36:14] It was with the __poll_chk branch [09:36:57] But i don't think it's related to the __poll_chk patch [09:37:04] It looks cfund related [09:40:12] @aguycalled maybe make a PR with the patch you sent here, so we can merge into master and hopefully when people test the RC, maybe we can get additional debug info [11:10:46] @aguycalled Can you make a PR with the patch that you send here? [11:11:16] I mean this: diff --git a/src/consensus/cfund.cpp b/src/consensus/cfund.cpp index aa8f00c2..9ef69440 100644 --- a/src/consensus/cfund.cpp +++ b/src/consensus/cfund.cpp @@ -397,6 +397,8 @@ CAmount CFund::CProposal::GetAvailable(CCoinsViewCache& coins, bool fIncludeRequ CAmount initial = nAmount; CPaymentRequestMap mapPaymentRequests; + LogPrintf("[CFUND] >> Checking available balance for proposal %s\n", [11:11:17] ToString(coins, chainActive.Tip()->GetBlockTime())); + if(coins.GetAllPaymentRequests(mapPaymentRequests)) { for (CPaymentRequestMap::iterator it_ = mapPaymentRequests.begin(); it_ != mapPaymentRequests.end(); it_++) @@ -419,7 +421,10 @@ CAmount CFund::CProposal::GetAvailable(CCoinsViewCache& coins, bool fIncludeRequ continue; } if((fIncludeRequests && prequest.fState != REJECTED [11:11:17] && prequest.fState != EXPIRED) || (!fIncludeRequests && prequest.fState == ACCEPTED)) + { + LogPrintf("[CFUND] >> Substracting %d from payment request %s\n", prequest.ToString()); initial -= prequest.nAmount; + } } } return initial; [11:11:32] yes i just want to include a bit more of log just in case, figuring out what else could help [11:11:40] Ok [11:11:47] Let me know when you have it, I'll review [11:12:08] will have it before my lunch [11:12:09] I'm still running another full sync [11:12:22] Hopefully it fails this time [11:12:28] Last 2 times worked properly [11:44:43] @aguycalled#1820 [11:44:45] About the DNS seed [11:44:56] You have a readme on how to run a mirror? [11:45:25] Also, how does BTC find peers? And does upstream use a DNS seed as well? [11:47:24] ok I managed to complete a docker build 🎉 [11:47:45] I think I was just having memory issues before [11:48:30] @mxaddict you're right this is infinitely more simple to set up compared to lxc [11:49:52] Yes, this is why we switched to docker, it saves so much time. [11:50:02] I built #549 [11:50:03] Good to hear it worked. [11:57:19] So does it not crash anymore? @mc290 [11:59:27] Nope [12:00:58] @prole I approved #549. It doesn't crash anymore but I haven't tested syncing, etc [12:01:49] nice [12:01:56] Hopefully we can get more people building gitian builds now that the process is so simple [12:01:58] #549 also builds for me. im currently still reindexing [12:02:05] up to block 2.6 million [12:02:13] so should be done when i wake up lol [12:02:18] Haha [12:02:26] but no problems so far [12:09:05] https://github.com/navcoin/navcoin-seeder/blob/master/README [12:09:08] @mxaddict [12:09:23] its a fork from bitcoins seeder they also usenit [12:09:26] use it* [12:11:05] I wonder if we could make a way to do peer discovery completely decentralized [12:11:11] I've a json output of the data from navcoin-seeder which i've had running for a few months. [12:11:13] https://api.navexplorer.com/api/network/nodes [12:11:15] I can't think of a way as of yet. [12:13:34] @mc290 that is the idea, make the barrier to entry low, so we can get more help. [12:14:03] Trying to automate most of the dev/build process to get more people onboard [12:14:12] We need all the help we can get [12:14:31] The more 👀 the better [12:15:25] @aguycalled we use libunbound for the dns stuff right? I don't see upstream using it. You know what they use? [12:29:00] libunbound is used for openalias [12:29:40] because we need to check dnssec to prevent usurpation attacks [12:30:23] for the dns seed i think its just a mini dns client [12:30:50] using some standard functions i think [12:31:37] Ahh [12:31:49] I thought we used unbound for the seed stuff [12:31:59] So it's used for openalias, gotcha [12:37:08] https://cdn.discordapp.com/attachments/416000318149754881/595925991080329237/Screen_Shot_2019-07-03_at_10.36.46_PM.png [12:37:36] 😭 [12:38:17] https://www.navexplorer.com/block/2762327 [12:39:24] @prole can you backup your datadir and maybe share with alex [12:39:31] That looks like similar error to what I dot [12:40:11] Can the explorer find itself forked in this same manner? [12:40:11] Also, once you've backed up the datadir, try fixing with : reconsiderblock e5e9e23e134e4bd4b4a88542b4fd771373a6c6420eb3a48a7145dd5c2e1b5692 [12:40:19] If that fixes it, then it's same issue that I had [12:40:41] @prodpeak not sure, only seems to happen on full syncs [12:41:00] I think it's possible, but unlikely, we need to fix it anyway. [12:41:06] Still trying to find out the cause [12:41:14] okay [12:41:38] im still posting the community roundtable article around [12:41:45] ill try to post it somewhere or at least get it uploading [12:41:47] Yeah, I saw that 😄 [12:41:51] I gave some claps 😄 [12:41:55] its gettin pretty late here and my brain is starting to cook [12:42:00] i need to go to bed soon [12:42:10] And liked/tweeted [12:42:23] Ai'ght, ttyl man [12:42:31] 👍 [12:42:53] If you share the datadir, I can maybe also take a look at it to try and debug more [12:43:21] It's hard to nip the bug as it's seamingly random blocks that it happens on [12:46:39] im taring the block, chainstate folders + debug.log for you guys [12:46:45] Thanks [12:56:09] uploading to s3 now [12:59:33] i did reconsider block on the invalid block and nothing seemed to happen [12:59:39] so i did it on the previous block [12:59:53] which is the output of getbestblockhash [12:59:58] and it started syncing again [13:00:15] but it could just have been that it took a while to find some peers because id dropped connections iwth everyone [13:00:25] so i dont know which reconsider did it [13:00:29] and the debug didnt really help [13:00:41] I actually had to unban my peers [13:00:47] right [13:00:55] So I think the first reconsider proly did it [13:00:56] seems mine was able to recover and find peers after some seconds [13:01:04] I see [13:01:19] maybe i hadn't banned everyone yet [13:01:20] 😛 [13:01:34] the tar is about half way uploaded [13:01:37] so shouldnt be too much longer [13:01:43] i will post hte link before i go to sleep [13:02:52] well [13:02:55] the link should be this; https://s3.amazonaws.com/navcoin-bootstrap/invalidblock2762327.tar [13:02:56] Ok, thanks [13:02:58] when it finishes uploading [13:03:05] ACK [13:04:29] also, is it just me or does the status bar not seem to be hte right length? [13:04:37] https://cdn.discordapp.com/attachments/416000318149754881/595932906208231426/Screen_Shot_2019-07-03_at_11.04.13_PM.png [13:04:52] 25 weeks behind and hte bar is only just over half way? [13:05:01] the first block is multiple years ago [13:05:13] so either its incorrect or not linear or something [13:06:56] okay, download finished [13:06:56] https://navcoin-bootstrap.s3.amazonaws.com/invalidblock2762327.tar [13:07:30] im off to bed, will talk in the morning [13:09:07] It's same logic as with BTC, I think the back is for blocks not the time [13:09:32] So it's longer towards the end, as I think more tx data in newer blocks [13:10:14] TTYL @prole [13:11:21] @prole why was the block marked as invalid [13:11:23] ? [13:11:42] could you check in the debug.log? [13:13:47] He uploaded the blocks,chainstate + debug.log [13:14:02] I'm downloading now to see if I can find something [13:20:01] the bootstrap does not use to include the log [13:20:19] ok its here in this [13:21:33] Yeah, he created a custom tar [13:31:54] there's no info on the log why it is invalid [13:32:08] Hmmm [13:32:15] I'm still downloading [13:32:38] But how did it get marked as invalid then? [13:32:49] if the log does not say it i can't know [13:33:13] That's a bummer [13:34:48] @aguycalled is the node that you are running built with gitian? or natively on the host you are testing on? [13:35:07] all my nodes are compiled natively [13:35:26] Hmm, maybe the issue is only on the gitian built bins [13:35:44] I'm not sure if @prole used a natively built or gitian built [13:35:52] But the node that had the issue for me was gitian built [13:36:01] i don't think this is related to your issue [13:36:29] Ok, just trying to eliminate as many variables as possible [13:36:32] e5e9e23e134e4bd4b4a88542b4fd771373a6c6420eb3a48a7145dd5c2e1b5692 is not cfund related [13:37:33] I see [13:38:03] Might not be related to cfund then, maybe the block that got marked invalid on my node just happened to be a cfund related block [13:38:14] But maybe the issue is not actually anything to do with cfund [13:39:04] IE some other code on the node messed up the block data, and then when cfund validatation runs, it marked it as invalid cause of the messed up data [13:40:18] Is there a way to get the RAW data from a block? [13:40:33] IE the block that is marked invalid? [13:40:44] So maybe we can compare to a valid copy of the block [13:40:57] the hash ensures the integrity of the block [13:41:05] if theres a single bit which is wrong then the hash would be different [13:41:19] Hmmm, all data in block is part of the hash? [13:41:31] yep [13:41:37] If so, then why does doing reconsiderblock fix the issue? [13:41:56] some state related issue, threading, dbs... [13:42:04] Hmmm [13:42:06] that's what my intuition say [13:42:10] Ahh, similar to the nBits one [13:42:46] Where some thread issue is causing it to mark invalid because of a timing/order of functions [13:42:55] yes [13:43:01] ACK [13:43:18] actually ive been fighting for some days with something similar in the dao implementation [13:43:39] where vote caches suddenly disappear in random blocks [13:44:42] You think it's related? [13:46:04] they share a random behaviour [13:49:55] Did we ever have this issue in 4.6.0 ? [13:50:03] Or older versions? [13:50:25] Yeah, the randomnes is what's making it hard to pinpoint [13:50:45] maybe the original cfund db bug was not related to the cfund db and was related to this, so that's why it's still happening [13:51:40] Possible [13:52:03] But merging the db was good too, so that if the wallet crashed it would not cause a problem between the dbs [13:52:35] When the dbs were seperated they would possibly have different best blocks right? [13:52:47] yes [13:52:48] I mean if a crash occured and the block data was not flushed to disk yet [18:08:20] @mxaddict Build essentials was installed. The only difference between now and the previous install is that navcoin-core is in my home folder and not with my system files. [18:13:35] I don't think that's the cause [18:13:41] Try installing libtool and autoconf [18:13:57] sudo apt install libtool autoconf [18:18:25] Thanks, I'll try the make -j8 again. [18:19:48] You will need to re-run the ./configure step [18:20:05] As that is where the last error was [18:20:08] 👌 [18:21:06] 👌 [18:58:04] @mxaddict Can't seem to find ./navcoin-qt, closest thing is navcoin-qt.dSYM in the qt folder. [19:00:49] sda6@sda6-Z68X-UD4-B3:~/gitcola/navcoin-core/src/qt$ ./navcoin-qt bash: ./navcoin-qt: No such file or directory [19:01:08] what's the output of make? [19:02:21] where do I find that? [19:03:59]