12016-11-09T00:07:03 *** btcdrak has joined #bitcoin-core-dev
22016-11-09T00:22:56 *** veleiro has joined #bitcoin-core-dev
32016-11-09T00:33:56 *** AaronvanW has quit IRC
42016-11-09T00:45:26 <sdaftuar> cfields: i think it'd also get tricky because the CValidationState passed in to ProcessNewBlock can be referencing a different block than where it might be used in ActivateBestChainStep
52016-11-09T00:45:43 <sipa> sdaftuar: good point
62016-11-09T00:51:17 <cfields> sdaftuar: yes, makes sense. thanks.
72016-11-09T01:03:13 *** davec has quit IRC
82016-11-09T01:19:44 <bitcoin-git> [bitcoin] TheBlueMatt closed pull request #9014: Fix block-connection performance regression (master...2016-10-fix-tx-regression) https://github.com/bitcoin/bitcoin/pull/9014
92016-11-09T01:24:50 *** davec has joined #bitcoin-core-dev
102016-11-09T01:42:27 *** jtimon has joined #bitcoin-core-dev
112016-11-09T01:42:46 <BlueMatt> jtimon: so i think i need to revert #9087 for #9075
122016-11-09T01:42:47 <gribble> https://github.com/bitcoin/bitcoin/issues/9087 | RPC: why not give more details when "generate" fails? by jtimon · Pull Request #9087 · bitcoin/bitcoin · GitHub
132016-11-09T01:42:49 <gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
142016-11-09T01:43:06 <BlueMatt> because 9074 removes the state parameter from ProcessNewBlock - it only is used if CheckBlock fails, not if there is an actual failure
152016-11-09T01:45:22 <jtimon> #9087 is just something I found while trying to fix the blocksigning branch, but it surprises me that you need to revert it
162016-11-09T01:45:24 <gribble> https://github.com/bitcoin/bitcoin/issues/9087 | RPC: why not give more details when "generate" fails? by jtimon · Pull Request #9087 · bitcoin/bitcoin · GitHub
172016-11-09T01:45:54 <BlueMatt> well it already doesnt work - the state object to ProcessNewBlock is only used if CheckBlock fails, not if the block is invalid for any other reason
182016-11-09T01:46:09 <BlueMatt> the only way to get useful info from ProcessNewBlock is to register, then de-register a CValidationInterface, already
192016-11-09T01:46:12 <BlueMatt> so I was removing it
202016-11-09T01:46:21 <sipa> or if processblock doens't run... if someone another new block was received?
212016-11-09T01:46:24 <sipa> *somehow
222016-11-09T01:46:41 <jtimon> oh, I see, and in my case it was failing on checkblockheader
232016-11-09T01:47:16 <jtimon> so with 9087 I was able to see "high hash"
242016-11-09T01:47:31 <BlueMatt> if someone actually cares, I can fix it by doing the register, de-register hack
252016-11-09T01:47:41 <BlueMatt> but....its a dirty hack
262016-11-09T01:48:28 <jtimon> btw, after you matt took the time check out checkblockheader is just like checkpow but putting a message on the validation state and with and absurd bool arg
272016-11-09T01:48:31 <sipa> jtimon: assuming the block wasn't reorged out, for what reason other than high hash would generate fail?
282016-11-09T01:49:52 <jtimon> feel free to revert the change, I can always have it locally, it shouldn't normally fail anyway, just because I'm doing another version of checkpow for the block signing stuff
292016-11-09T01:50:35 <sipa> jtimon: with matt's change, processnewblock doesn't take a CValidateState anymore
302016-11-09T01:51:02 <jtimon> I just thought there was no harm and maybe was useful in more cases besides mine, seriously, no need to pass CValidateState to processnewblock only for rpc/mining
312016-11-09T01:51:12 <sipa> BlueMatt, jtimon: perhaps it can be fixed by invoking AcceptNewHeader explicitly from RPC, and report the result from that?
322016-11-09T01:51:31 <BlueMatt> ehh, please no...CheckBlock
332016-11-09T01:51:35 <BlueMatt> not Accept*Header
342016-11-09T01:51:40 <sipa> ah
352016-11-09T01:51:42 <sipa> ok
362016-11-09T01:52:21 <jtimon> I can do it locally if I need to, but right now I know where the things are failing, just don't understand why, please feel free to revert 9087, np
372016-11-09T01:53:06 <BlueMatt> ok
382016-11-09T01:53:28 <jtimon> it just felt kind of free to upstream
392016-11-09T01:53:40 <BlueMatt> yupyup, all right decisions, just randomly gets in the way :)
402016-11-09T01:54:14 <jtimon> ok, good, same page it seems
412016-11-09T01:56:15 <jtimon> sipa: the last idea may be interesting for mining::generate though
422016-11-09T01:56:51 <jtimon> but yeah, later
432016-11-09T01:57:15 *** abpa has quit IRC
442016-11-09T01:59:06 <jtimon> does it make sense for me to try that the custom chain (by default just like regstes, just with a different genesis block and a different directory) passes all rpc python tests just like regtest does?
452016-11-09T02:00:09 *** Ylbam has quit IRC
462016-11-09T02:00:17 *** fengling has joined #bitcoin-core-dev
472016-11-09T02:00:47 <jtimon> never mind, I'll try first, ask later
482016-11-09T02:17:57 *** btcdrak has quit IRC
492016-11-09T02:18:31 *** DigiByteDev has joined #bitcoin-core-dev
502016-11-09T02:22:01 *** afk11_ has quit IRC
512016-11-09T02:23:18 *** afk11 has joined #bitcoin-core-dev
522016-11-09T02:23:18 *** afk11 has quit IRC
532016-11-09T02:23:18 *** afk11 has joined #bitcoin-core-dev
542016-11-09T02:41:40 *** grubles has quit IRC
552016-11-09T02:43:59 *** Squidicuz has joined #bitcoin-core-dev
562016-11-09T02:54:57 *** grubles has joined #bitcoin-core-dev
572016-11-09T03:18:18 *** Chris_Stewart_5 has quit IRC
582016-11-09T03:27:01 *** To7 has quit IRC
592016-11-09T03:31:30 *** Chris_Stewart_5 has joined #bitcoin-core-dev
602016-11-09T03:39:49 *** Chris_Stewart_5 has quit IRC
612016-11-09T03:57:06 *** btcdrak has joined #bitcoin-core-dev
622016-11-09T03:59:20 *** abpa has joined #bitcoin-core-dev
632016-11-09T04:03:42 *** fanquake has joined #bitcoin-core-dev
642016-11-09T04:04:24 *** jtimon has quit IRC
652016-11-09T04:12:44 *** justanotheruser has quit IRC
662016-11-09T04:15:50 *** justanotheruser has joined #bitcoin-core-dev
672016-11-09T04:39:12 *** shesek has quit IRC
682016-11-09T04:53:45 *** veleiro has quit IRC
692016-11-09T05:14:02 *** juscamarena has quit IRC
702016-11-09T05:18:00 *** go1111111 has joined #bitcoin-core-dev
712016-11-09T05:40:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
722016-11-09T05:42:01 *** fengling has quit IRC
732016-11-09T05:49:10 *** davec has quit IRC
742016-11-09T05:58:39 *** Chris_Stewart_5 has quit IRC
752016-11-09T06:07:36 *** wasi has quit IRC
762016-11-09T06:07:37 *** testnet has quit IRC
772016-11-09T06:09:08 *** fengling has joined #bitcoin-core-dev
782016-11-09T06:10:44 *** davec has joined #bitcoin-core-dev
792016-11-09T06:11:20 *** Giszmo has quit IRC
802016-11-09T06:11:51 *** wasi has joined #bitcoin-core-dev
812016-11-09T06:11:57 *** testnet has joined #bitcoin-core-dev
822016-11-09T06:16:05 *** DigiByteDev has quit IRC
832016-11-09T06:17:57 *** btcdrak has quit IRC
842016-11-09T06:49:29 *** DigiByteDev has joined #bitcoin-core-dev
852016-11-09T07:11:53 *** btcdrak has joined #bitcoin-core-dev
862016-11-09T07:36:34 *** LeMiner2 has joined #bitcoin-core-dev
872016-11-09T07:39:04 *** LeMiner has quit IRC
882016-11-09T07:39:04 *** LeMiner2 is now known as LeMiner
892016-11-09T07:47:19 *** BashCo has quit IRC
902016-11-09T07:59:43 *** DigiByteDev has quit IRC
912016-11-09T08:10:49 *** BashCo has joined #bitcoin-core-dev
922016-11-09T08:18:04 *** DigiByteDev has joined #bitcoin-core-dev
932016-11-09T08:18:37 *** davec has quit IRC
942016-11-09T08:20:41 *** davec has joined #bitcoin-core-dev
952016-11-09T08:25:13 *** rubensayshi has joined #bitcoin-core-dev
962016-11-09T08:32:49 *** davec has quit IRC
972016-11-09T08:34:28 *** davec has joined #bitcoin-core-dev
982016-11-09T09:04:56 *** AaronvanW has joined #bitcoin-core-dev
992016-11-09T09:04:56 *** AaronvanW has quit IRC
1002016-11-09T09:04:56 *** AaronvanW has joined #bitcoin-core-dev
1012016-11-09T09:10:22 *** ChillazZ has joined #bitcoin-core-dev
1022016-11-09T09:10:48 *** ChillazZ is now known as Guest82720
1032016-11-09T09:13:34 *** laurentmt has joined #bitcoin-core-dev
1042016-11-09T09:16:08 *** rebroad has joined #bitcoin-core-dev
1052016-11-09T09:16:35 <rebroad> gmaxwell, wumpus, sipa, I think I may have found a bug that can crash bitcoin nodes
1062016-11-09T09:17:15 <rebroad> potential DoS
1072016-11-09T09:17:44 <Victorsueca> rebroad: in latest version?
1082016-11-09T09:17:48 <rebroad> yes
1092016-11-09T09:18:18 <rebroad> or at least, someone else found it and used it against my node
1102016-11-09T09:18:24 <rebroad> but it's easy to fix
1112016-11-09T09:18:39 <jonasschnelli> rebroad: Does it crash or do you just get an exception?
1122016-11-09T09:18:43 <rebroad> crashes
1132016-11-09T09:18:47 <rebroad> well, both
1142016-11-09T09:19:06 <jonasschnelli> I guess we are talking about 9110
1152016-11-09T09:19:07 <jonasschnelli> PR #9110
1162016-11-09T09:19:08 <gribble> https://github.com/bitcoin/bitcoin/issues/9110 | CInv::GetCommand(): type=1373179482 unknown type · Issue #9110 · bitcoin/bitcoin · GitHub
1172016-11-09T09:19:15 <rebroad> yes
1182016-11-09T09:19:31 <rebroad> only if debug=net though
1192016-11-09T09:19:37 <rebroad> the "got inv" debug messsage
1202016-11-09T09:20:09 <jonasschnelli> Okay...
1212016-11-09T09:20:19 <Victorsueca> sounds like bitcoin core fails some assertion in there
1222016-11-09T09:20:23 <paveljanik> please add the info about debug=net to the PR...
1232016-11-09T09:21:18 *** laurentmt has quit IRC
1242016-11-09T09:21:18 <Victorsueca> rebroad: it crashes only with debug=net enabled? or it still crashes anyway but without log exception when disabled?
1252016-11-09T09:21:27 <rebroad> I have changed the code to simply strprintf an unknown and I think this should be an ok fix.. not tested sufficiently yet (as I don't have code to generate invalid inv messages yet)
1262016-11-09T09:21:49 <rebroad> Victorsueca, I suspect it'll only crash if debug=net but not tested with it not set yet
1272016-11-09T09:22:37 <rebroad> but someone out there is already sending these invalid invs... the address it came from was 50.254.73.145
1282016-11-09T09:23:13 <Victorsueca> if that's the case then it would be a bug at generating the exception warning message or writing it to the log
1292016-11-09T09:23:25 <jonasschnelli> I though ProcessMessages() executes always in a try/catch...
1302016-11-09T09:23:31 *** montau is now known as whphhg
1312016-11-09T09:23:53 <rebroad> it's is possible that I have made a change that is making it vulnerable
1322016-11-09T09:24:02 <jonasschnelli> I think so...
1332016-11-09T09:24:07 <jonasschnelli> Going to test this now...
1342016-11-09T09:24:07 <rebroad> I don't think I have, but it's not beyond belief
1352016-11-09T09:24:22 *** DigiByteDev has quit IRC
1362016-11-09T09:24:38 *** fengling has quit IRC
1372016-11-09T09:24:55 <Victorsueca> maybe somebody should make a honeypot and wireshark it to see what message is causing this
1382016-11-09T09:25:06 <jonasschnelli> rebroad: you could try to reproduce the issue on master with a simple new RPC test (maybe called invalidinv.py)
1392016-11-09T09:25:13 <jonasschnelli> Victorsueca: it's simple to test... no need for a honeypot
1402016-11-09T09:25:39 <paveljanik> rebroad, and in every case: responsible disclosure next time, please...
1412016-11-09T09:26:28 <Victorsueca> ^ yeah, this things should be PGPed to the team
1422016-11-09T09:26:52 <jonasschnelli> Indeed (if you think your right)
1432016-11-09T09:27:58 <wumpus> I'm fairly sure tI've tried to do this before, though probably not with debug=net
1442016-11-09T09:28:34 *** rebroad has quit IRC
1452016-11-09T09:32:45 *** fanquake has quit IRC
1462016-11-09T09:33:23 *** fanquake has joined #bitcoin-core-dev
1472016-11-09T09:33:37 *** DigiByteDev has joined #bitcoin-core-dev
1482016-11-09T09:33:42 <wumpus> it'd need to call CInv::ToString or CInv::GetCommand to get this exception, indeed something that only happens with debugging on
1492016-11-09T09:33:58 <wumpus> I think it's somewhat unexpected for a ToString call to raise an exception
1502016-11-09T09:34:06 <wumpus> however the exception should not crash the program
1512016-11-09T09:39:55 <Victorsueca> the log says something about St12out_of_range, that sounds like something that was asserted to be within certain range is not
1522016-11-09T09:40:04 <Victorsueca> maybe the type number?
1532016-11-09T09:41:04 <fanquake> wumpus Yes you have. See #1625
1542016-11-09T09:41:05 <gribble> https://github.com/bitcoin/bitcoin/issues/1625 | Bitcoin-Qt: exception in CInv::GetCommand() when using -onlynet="IPv6" · Issue #1625 · bitcoin/bitcoin · GitHub
1552016-11-09T09:41:28 <fanquake> So we've seen this/a similar issue before.
1562016-11-09T09:41:49 <wumpus> managed to get the message in the log, however no crash
1572016-11-09T09:51:29 *** fengling has joined #bitcoin-core-dev
1582016-11-09T09:54:03 <bitcoin-git> [bitcoin] fanquake opened pull request #9111: Remove unused variable UNLIKELY_PCT from fees.h (master...remove-unused-unlikely-pct) https://github.com/bitcoin/bitcoin/pull/9111
1592016-11-09T09:54:29 *** ratoder has quit IRC
1602016-11-09T10:05:43 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/924de0bd75a7...e9847303e708
1612016-11-09T10:05:44 <bitcoin-git> bitcoin/master addfdeb Andrew Chow: Multiple Selection for peer and ban tables...
1622016-11-09T10:05:44 <bitcoin-git> bitcoin/master 1077577 Andrew Chow: Fix auto-deselection of peers
1632016-11-09T10:05:45 <bitcoin-git> bitcoin/master e984730 Wladimir J. van der Laan: Merge #8874: Multiple Selection for peer and ban tables...
1642016-11-09T10:11:53 *** rebroad has joined #bitcoin-core-dev
1652016-11-09T10:13:07 <rebroad> apologies for the less than ideal disclosure... I purposefully did not mention the issue I'd raised on here for that reason (bad internet here, otherwise I'd already have wiped the issue the moment it got mentioned)
1662016-11-09T10:16:36 <bitcoin-git> [bitcoin] laanwj opened pull request #9112: Avoid ugly exception in log on unknown inv type (master...2016_11_invtype_debugging) https://github.com/bitcoin/bitcoin/pull/9112
1672016-11-09T10:25:20 <bitcoin-git> [bitcoin] rebroad opened pull request #9113: Return the type when it's unknown instead of throwing an exception (master...ReturnNotThrow) https://github.com/bitcoin/bitcoin/pull/9113
1682016-11-09T10:47:24 *** DigiByteDev has quit IRC
1692016-11-09T11:01:16 <bitcoin-git> [bitcoin] fanquake opened pull request #9114: [depends] Set OSX_MIN_VERSION to 10.8 (master...depends-min-osx-10-8) https://github.com/bitcoin/bitcoin/pull/9114
1702016-11-09T11:10:38 *** LeMiner2 has joined #bitcoin-core-dev
1712016-11-09T11:12:48 *** LeMiner has quit IRC
1722016-11-09T11:12:48 *** LeMiner2 is now known as LeMiner
1732016-11-09T11:15:20 *** DigiByteDev has joined #bitcoin-core-dev
1742016-11-09T11:23:12 *** cdecker has joined #bitcoin-core-dev
1752016-11-09T11:23:43 *** aalex has joined #bitcoin-core-dev
1762016-11-09T11:25:17 *** rebroad has quit IRC
1772016-11-09T11:28:59 <jonasschnelli> I have started with the BIP151 implementation and are trying to split it into different PRs, though, not sure how easy that is.
1782016-11-09T11:34:56 <wumpus> indeed, for next time: if you suspect a remote-triggerable crash bug, even if you're not sure, please don't immediately throw it in here, but use private ways of contacting
1792016-11-09T11:36:33 <wumpus> </panicmode>
1802016-11-09T11:37:24 *** Giszmo has joined #bitcoin-core-dev
1812016-11-09T11:37:26 <wumpus> jonasschnelli: at least coordinate with cfields on the network level changes
1822016-11-09T11:54:37 <bitcoin-git> [bitcoin] paveljanik opened pull request #9115: Mention reporting security issues responsibly (master...20161109_secissues) https://github.com/bitcoin/bitcoin/pull/9115
1832016-11-09T12:01:05 *** DigiByteDev has quit IRC
1842016-11-09T12:03:07 *** fengling has quit IRC
1852016-11-09T12:07:08 *** davec has quit IRC
1862016-11-09T12:10:22 *** aalex has quit IRC
1872016-11-09T12:21:56 <bitcoin-git> [bitcoin] ondrejsika opened pull request #9116: Allow getblocktemlate for not connected regtest node (master...master) https://github.com/bitcoin/bitcoin/pull/9116
1882016-11-09T12:31:20 *** murch has joined #bitcoin-core-dev
1892016-11-09T12:37:33 <jonasschnelli> wumpus: Yes. Good idea. Not sure if a PR with the implementation of the new message format without the actual encryption itself could make sense.
1902016-11-09T12:48:01 *** rebroad has joined #bitcoin-core-dev
1912016-11-09T12:52:31 <bitcoin-git> [bitcoin] laanwj pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/e9847303e708...e81df49644c2
1922016-11-09T12:52:32 <bitcoin-git> bitcoin/master 50e8a9c Pieter Wuille: Remove unused ReadVersion and WriteVersion...
1932016-11-09T12:52:33 <bitcoin-git> bitcoin/master c2c5d42 Pieter Wuille: Make streams' read and write return void...
1942016-11-09T12:52:33 <bitcoin-git> bitcoin/master fad9b66 Pieter Wuille: Make nType and nVersion private and sometimes const...
1952016-11-09T12:52:41 <bitcoin-git> [bitcoin] laanwj closed pull request #9039: Various serialization simplifcations and optimizations (master...simpleserial) https://github.com/bitcoin/bitcoin/pull/9039
1962016-11-09T12:56:43 *** rebroad has quit IRC
1972016-11-09T13:03:59 *** MarcoFalke has joined #bitcoin-core-dev
1982016-11-09T13:11:54 *** rebroad has joined #bitcoin-core-dev
1992016-11-09T13:12:42 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/e81df49644c2...e0477f6d2072
2002016-11-09T13:12:43 <bitcoin-git> bitcoin/master fd5654c Pavel JanÃk: Check and enable -Wshadow by default.
2012016-11-09T13:12:43 <bitcoin-git> bitcoin/master 359bac7 Pavel JanÃk: Add notes about variable names and shadowing
2022016-11-09T13:12:44 <bitcoin-git> bitcoin/master e0477f6 Wladimir J. van der Laan: Merge #8794: Enable -Wshadow by default...
2032016-11-09T13:12:52 <bitcoin-git> [bitcoin] laanwj closed pull request #8794: Enable -Wshadow by default (master...20160922_Wshadow_enable) https://github.com/bitcoin/bitcoin/pull/8794
2042016-11-09T13:43:45 <jonasschnelli> cfields: net.h what's the advantage of using a Callable (ForEachNodeContinueIf(Callable&& func)) instead of just passing in a std::function?
2052016-11-09T13:51:29 *** aalex has joined #bitcoin-core-dev
2062016-11-09T13:51:37 <cfields> jonasschnelli: so that lambdas are overhead-free
2072016-11-09T13:55:19 <jonasschnelli> cfields: can you explain me what kind of overhead? (Sorry to bother you with basic c++)
2082016-11-09T13:57:13 <cfields> jonasschnelli: np. std::function necessarily does an allocation, is copyable, etc. But lambdas can essentially create inline code.
2092016-11-09T13:58:24 <cfields> by using a callable, you can pass in a lambda for "free", or pass in a std::function for flexibility. It gives the flexibility of both.
2102016-11-09T13:59:10 <cfields> (maybe I should've mentioned that earlier. You can pass a std::function into it if you'd like, it'll work as you'd want it to)
2112016-11-09T14:00:32 <jonasschnelli> cfields: here I pass in Lambda https://github.com/bitcoin/bitcoin/pull/9076/files#diff-b2bb174788c7409b671c46ccc86034bdR3824 ... the function structure defines the parameter as std::function, does this always result in a copy for the lambda?
2122016-11-09T14:00:35 *** Ylbam has joined #bitcoin-core-dev
2132016-11-09T14:01:22 *** Guyver2 has joined #bitcoin-core-dev
2142016-11-09T14:01:55 <cfields> jonasschnelli: yes. a std::function is constructed there.
2152016-11-09T14:02:49 <jonasschnelli> Okay. So changing it to a callable would be more efficient.. right?
2162016-11-09T14:02:56 <jonasschnelli> (reducing a copy)
2172016-11-09T14:03:53 <cfields> jonasschnelli: yep, assuming you can neatly use a template in the definition
2182016-11-09T14:05:15 *** murch has quit IRC
2192016-11-09T14:06:37 <cfields> jonasschnelli: think of it like something "printable". You could pass the constant "foo" into a "Print(std::string s) { printf("string" %s, s); }, which will construct a std::string just to throw it away
2202016-11-09T14:07:14 <jonasschnelli> cfields: Thanks. I think I see you point now.
2212016-11-09T14:07:21 <cfields> but if you used "template <typename T> Print(T&& s) { std::cout << s; }, you can pass in a raw string for free
2222016-11-09T14:18:44 *** davec has joined #bitcoin-core-dev
2232016-11-09T14:19:30 <fanquake> paveljanik I'm probably wrong, but the hex/line numbers was the first thing that jumped out at me.
2242016-11-09T14:20:01 <paveljanik> fanquake, sure. But this is probably some issue on the builder side as it does not touch leveldb at all...
2252016-11-09T14:20:56 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2262016-11-09T14:24:51 <MarcoFalke> I think I was hitting the assert in net.h https://github.com/bitcoin/bitcoin/blob/e9847303e708ab71b4d2c22ceb7d65c89615e18a/src/net.h#L772 ... I couldn't reproduce and debug.log only says ProcessMessages(version, 102 bytes) FAILED peer=10 http://pastebin.ubuntu.com/23451144/
2272016-11-09T14:25:29 *** sdaftuar has quit IRC
2282016-11-09T14:26:08 *** ryanofsky has quit IRC
2292016-11-09T14:27:42 *** sdaftuar has joined #bitcoin-core-dev
2302016-11-09T14:35:18 *** sdaftuar has quit IRC
2312016-11-09T14:37:20 *** sdaftuar has joined #bitcoin-core-dev
2322016-11-09T14:39:04 *** ryanofsky has joined #bitcoin-core-dev
2332016-11-09T14:46:16 <cfields> MarcoFalke: yes, i assumed that would cause a few crashes for the first few days
2342016-11-09T14:47:54 <cfields> MarcoFalke: can you run with -debug for a while?
2352016-11-09T14:48:06 <MarcoFalke> sure
2362016-11-09T14:49:05 <cfields> MarcoFalke: the issue is: we continue to send messages, even after the handshake has failed and we've decided to disconnect. I think it's a good thing to find out what those cases are.
2372016-11-09T14:53:34 *** rebroad has quit IRC
2382016-11-09T14:55:28 *** shesek has joined #bitcoin-core-dev
2392016-11-09T14:57:17 *** fanquake has left #bitcoin-core-dev
2402016-11-09T15:06:18 *** Chris_Stewart_5 has quit IRC
2412016-11-09T15:18:26 *** abpa has quit IRC
2422016-11-09T15:28:47 *** jtimon has joined #bitcoin-core-dev
2432016-11-09T15:54:12 *** laurentmt has joined #bitcoin-core-dev
2442016-11-09T16:00:44 *** laurentmt has quit IRC
2452016-11-09T16:01:57 *** whphhg has joined #bitcoin-core-dev
2462016-11-09T16:17:38 *** ryanofsky has quit IRC
2472016-11-09T16:17:47 *** sdaftuar has quit IRC
2482016-11-09T16:19:28 *** sdaftuar has joined #bitcoin-core-dev
2492016-11-09T16:21:43 *** Guyver2__ has joined #bitcoin-core-dev
2502016-11-09T16:23:23 <MarcoFalke> cfields: Prob when expected != offered. See debug.log: https://paste.fedoraproject.org/476493/87085851/
2512016-11-09T16:23:36 <MarcoFalke> or bt https://paste.fedoraproject.org/476491/08356147/
2522016-11-09T16:23:52 <cfields> MarcoFalke: perfect, thanks
2532016-11-09T16:24:42 <cfields> MarcoFalke: hmm, seems to be in sending the reject...
2542016-11-09T16:24:54 *** cysm has quit IRC
2552016-11-09T16:25:14 *** Guyver2 has quit IRC
2562016-11-09T16:25:15 <MarcoFalke> And what is the feefilter in the bt?
2572016-11-09T16:25:16 *** Guyver2__ is now known as Guyver2
2582016-11-09T16:26:20 <cfields> MarcoFalke: aha! I didn't see the bt
2592016-11-09T16:27:07 <cfields> MarcoFalke: yep, that's the problem.
2602016-11-09T16:28:26 <cfields> MarcoFalke: I'll pr a quick/dirty fix in a few min, and I'm working on a more robust solution
2612016-11-09T16:29:11 <cfields> MarcoFalke: quick fix: http://pastebin.com/raw/E8ZXsKYa
2622016-11-09T16:29:21 <MarcoFalke> that was quick :)
2632016-11-09T16:30:18 *** ryanofsky has joined #bitcoin-core-dev
2642016-11-09T16:30:53 <cfields> MarcoFalke: well like i said, I expected it to point out a few issues. They should all be very easy to fix individually.
2652016-11-09T16:31:08 <cfields> (as long as there's a nice log/backtrace, that is :)
2662016-11-09T16:49:18 *** abpa has joined #bitcoin-core-dev
2672016-11-09T17:06:50 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2682016-11-09T17:18:59 *** testnet has quit IRC
2692016-11-09T17:25:39 *** rubensayshi has quit IRC
2702016-11-09T17:28:55 *** BashCo has quit IRC
2712016-11-09T17:30:12 *** igno_peverell has joined #bitcoin-core-dev
2722016-11-09T17:30:21 *** igno_peverell has left #bitcoin-core-dev
2732016-11-09T17:40:17 *** ryanofsky has quit IRC
2742016-11-09T17:40:29 *** sdaftuar has quit IRC
2752016-11-09T17:41:51 *** testnet has joined #bitcoin-core-dev
2762016-11-09T17:42:18 *** sdaftuar has joined #bitcoin-core-dev
2772016-11-09T17:50:17 *** BashCo has joined #bitcoin-core-dev
2782016-11-09T17:53:28 *** ryanofsky has joined #bitcoin-core-dev
2792016-11-09T18:00:15 *** cysm has joined #bitcoin-core-dev
2802016-11-09T18:16:53 *** Chris_Stewart_5 has quit IRC
2812016-11-09T18:19:50 <bitcoin-git> [bitcoin] theuni opened pull request #9117: net: don't send feefilter messages before the version handshake is complete (master...feefilter-assert) https://github.com/bitcoin/bitcoin/pull/9117
2822016-11-09T18:20:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2832016-11-09T18:23:51 <sipa> jonasschnelli: i was planning to work on bip151, but i'm not going to touch anything before the ongoing net refactors are done :)
2842016-11-09T18:26:31 <gmaxwell> cfields: if the issue in 9117 is feefilter before handshake, should it not be checking fSuccessfullyConnected?
2852016-11-09T18:27:03 <cfields> jonasschnelli and i just discussed a bit, i'm making sure that the current refactors at least make bip151 not harder, but hopefully easier too
2862016-11-09T18:30:44 <cfields> gmaxwell: i suppose that would work too in this case. just that fDisconnected happens to also catch the case when we've just decided to disconnect after a successful handshake
2872016-11-09T18:31:08 <MarcoFalke> gmaxwell: I think the handshake was done in the case I saw above: https://paste.fedoraproject.org/476493/87085851/raw/
2882016-11-09T18:31:12 <cfields> er, at any time in the session after the handshake is done
2892016-11-09T18:31:49 <cfields> MarcoFalke: no, it's halfway done. We got their version and set it, but didn't like it, so didn't set a sendVersion
2902016-11-09T18:32:48 <gmaxwell> but it wouldn't catch cases where we weren't done but also weren't planning on disconnecting them?
2912016-11-09T18:34:35 <cfields> gmaxwell: i don't think that's a possibility
2922016-11-09T18:36:56 <cfields> gmaxwell: i'm cleaning up the disconnect logic atm so that it's hopefully more clear. I believe the only case where we'd want to send a message after we've set fDisconnect is for reject messages, no?
2932016-11-09T18:36:57 *** davec has quit IRC
2942016-11-09T18:37:56 <gmaxwell> I don't really think we should be sending any messages after flipping that flag.
2952016-11-09T18:40:11 *** davec has joined #bitcoin-core-dev
2962016-11-09T18:43:12 *** Chris_Stewart_5 has quit IRC
2972016-11-09T18:43:24 <cfields> hmm, may be able to make that work
2982016-11-09T18:49:37 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2992016-11-09T18:49:47 *** davec has quit IRC
3002016-11-09T18:53:19 <morcos> sipa: Did you intend for fImporting to be set during LoadMempool? It is now, but I thought that was a bug, indeed it causes pruning.py to fail b/c sync isn't happening during the potentially long process of loading the mempool. (fImporting causes IBD to be true)
3012016-11-09T18:54:02 <morcos> I was going to PR a fix, but I realize now that fee estimation conveniently ignores the LoadMempool txs due to this, so now it requires a lot more thinking about what the correct behavior is
3022016-11-09T18:55:38 <sipa> morcos: hmm, IBD should probably not be true during LoadMempool
3032016-11-09T18:59:28 *** davec has joined #bitcoin-core-dev
3042016-11-09T19:16:32 *** davec has quit IRC
3052016-11-09T19:18:47 *** davec has joined #bitcoin-core-dev
3062016-11-09T19:22:12 *** laurentmt has joined #bitcoin-core-dev
3072016-11-09T19:26:05 *** laurentmt has quit IRC
3082016-11-09T19:32:45 *** Chris_Stewart_5 has quit IRC
3092016-11-09T19:35:42 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3102016-11-09T19:37:58 *** btcdrak has quit IRC
3112016-11-09T19:44:09 *** davec has quit IRC
3122016-11-09T19:45:02 *** Guyver2 has quit IRC
3132016-11-09T19:48:14 *** Guyver2 has joined #bitcoin-core-dev
3142016-11-09T19:53:09 <gmaxwell> the build is now a _flood_ ofr shadowing warnings for me.
3152016-11-09T19:53:25 <gmaxwell> thousands of them.
3162016-11-09T19:53:57 <paveljanik> gmaxwell, what compiler? Can you upload the log please?
3172016-11-09T19:54:05 <gmaxwell> gcc version 6.1.1 20160802 (Debian 6.1.1-11)
3182016-11-09T19:54:07 <paveljanik> old gcc?
3192016-11-09T19:54:26 <sipa> that's a very new gcc
3202016-11-09T19:54:30 <sipa> i also get those warning
3212016-11-09T19:55:17 *** davec has joined #bitcoin-core-dev
3222016-11-09T19:55:21 <Chris_Stewart_5> Is the CHECKSIG operation missing in BIP141 for P2WPKH & P2WPKH nested inside of P2SH? https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh
3232016-11-09T19:56:20 <paveljanik> can you please upload the log somewhere?
3242016-11-09T19:57:10 <paveljanik> There is #8808 but maybe we need even more for new gcc
3252016-11-09T19:57:12 <gribble> https://github.com/bitcoin/bitcoin/issues/8808 | Do not shadow variables (gcc set) by paveljanik · Pull Request #8808 · bitcoin/bitcoin · GitHub
3262016-11-09T19:58:38 <gmaxwell> paveljanik: http://0bin.net/paste/C-XT2Ww24Gb0-oSk#gTvVzT2VMvRmjuKhVgAP25zWIpGHhJUbOKamb4KKFi-
3272016-11-09T20:00:32 <paveljanik> fFlushOnClose is fixed there
3282016-11-09T20:01:28 <paveljanik> gmaxwell, looks like you are good candidate for ACK on #8808 8)
3292016-11-09T20:01:29 <gribble> https://github.com/bitcoin/bitcoin/issues/8808 | Do not shadow variables (gcc set) by paveljanik · Pull Request #8808 · bitcoin/bitcoin · GitHub
3302016-11-09T20:01:43 <jonasschnelli> sipa: Okay. That's great news. I can re-focus then on the SPV mode.
3312016-11-09T20:03:59 <gmaxwell> Where did we turn on these Wshadow warnings?
3322016-11-09T20:06:17 <gmaxwell> oh, I'd already pulled it off while bisecting. 8794
3332016-11-09T20:10:20 *** davec has quit IRC
3342016-11-09T20:11:17 *** Chris_Stewart_5 has quit IRC
3352016-11-09T20:15:13 <paveljanik> yes, but 8808 is missing.
3362016-11-09T20:15:32 <paveljanik> and I'm now testing with a bit older gcc than yours...
3372016-11-09T20:16:02 <sipa> i can test with 6.2.0
3382016-11-09T20:16:26 <paveljanik> great! I will install the VM with some newer one later
3392016-11-09T20:19:56 *** davec has joined #bitcoin-core-dev
3402016-11-09T20:20:34 <phantomcircuit> gmaxwell: yeah we shadow things all over the place
3412016-11-09T20:21:46 <sipa> let's fix it
3422016-11-09T20:25:46 <wumpus> strange, I had no shadow warnings at all before I merged that
3432016-11-09T20:26:09 <wumpus> or maybe one in leveldb or so, but certainly no flood
3442016-11-09T20:26:12 <wumpus> I don't get it
3452016-11-09T20:26:14 <wumpus> going to revert
3462016-11-09T20:27:18 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3472016-11-09T20:27:23 <wumpus> maybe we shouldn't do it at all, it's too compiler-dependent
3482016-11-09T20:28:07 <sipa> i think all the difficulty we have in figuring out how to resolve the -Wshadow warning exactly shows what problems actual unintentional shadowing could have
3492016-11-09T20:28:36 <sipa> and there is a clear upper bound on what -Wshadow can mean... i'm a bit surprised there even is compiler dependence here
3502016-11-09T20:28:43 <gmaxwell> In C it's utterly unambigious and fine, I'm less sure about C++ but I expect it's good to enable. But we should eliminate all the warnings first. Very weird that you weren't seeing them!
3512016-11-09T20:29:05 <MarcoFalke> I could check #8808 with 6.2.1
3522016-11-09T20:29:07 <gribble> https://github.com/bitcoin/bitcoin/issues/8808 | Do not shadow variables (gcc set) by paveljanik · Pull Request #8808 · bitcoin/bitcoin · GitHub
3532016-11-09T20:29:14 <gmaxwell> (by all I mean almost all, of course, obviously I don't care about one in leveldb)
3542016-11-09T20:29:16 <wumpus> I'm not going to bother with it anymore, at least
3552016-11-09T20:29:38 <wumpus> not just me *multiple people* tested it here: https://github.com/bitcoin/bitcoin/pull/8794
3562016-11-09T20:29:39 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/f445d886126c00814c71b855fc2f36fdd7e11098
3572016-11-09T20:29:39 <bitcoin-git> bitcoin/master f445d88 Wladimir J. van der Laan: Revert "Check and enable -Wshadow by default."...
3582016-11-09T20:30:13 <wumpus> seems just needless busywork, how many 'prevent shadowing' commits have we had and it's still a problem
3592016-11-09T20:31:54 <gmaxwell> Coding convention wise, I notice that 8808 adds _ to many local variables. I think there moderately common convention for using _ on function parameters.
3602016-11-09T20:33:21 <gmaxwell> Many other things are wshadow with no issues, but we have classes with many flag generic top level names. like "bits", "flags", "nversion"... and a codebase that hasn't had the warning for a long time.
3612016-11-09T20:33:42 <wumpus> but those were supposed to be fixed already
3622016-11-09T20:33:47 <wumpus> where are you getting all these warnings?
3632016-11-09T20:34:13 <wumpus> can you maybe pastebin and post in that issue?
3642016-11-09T20:34:23 <gmaxwell> I pastebinned the warnings above: http://0bin.net/paste/C-XT2Ww24Gb0-oSk#gTvVzT2VMvRmjuKhVgAP25zWIpGHhJUbOKamb4KKFi-
3652016-11-09T20:34:26 <wumpus> maybe paveljanik would like to know
3662016-11-09T20:34:38 <gmaxwell> Glad to help squash them all.
3672016-11-09T20:34:59 <wumpus> jdid't we get rid of nVersion?
3682016-11-09T20:35:11 <sipa> of the serialize.h-based nVersion
3692016-11-09T20:35:21 <sipa> but there are still some nVersion variables scattered
3702016-11-09T20:35:33 <wumpus> nah, I think there's more important things
3712016-11-09T20:35:45 <wumpus> I thought this was done, but if there's another load of that bullshit
3722016-11-09T20:36:09 <gmaxwell> I really would like to understand how compliler differences came into play.
3732016-11-09T20:37:54 <wumpus> probably they consider slightly different scopes
3742016-11-09T20:41:21 *** Chris_Stewart_5 has quit IRC
3752016-11-09T20:42:16 * paveljanik back
3762016-11-09T20:42:33 <paveljanik> I first done Wshadow clean build on OS X/clang
3772016-11-09T20:42:39 <paveljanik> then tested on newer clang
3782016-11-09T20:42:46 <paveljanik> than newer clang on Linux
3792016-11-09T20:42:52 <paveljanik> then old gcc on Linux.
3802016-11-09T20:43:14 <paveljanik> I'm now Wshadow clean on all clangs available to me and one gcc version (after 8808).
3812016-11-09T20:43:36 <paveljanik> There are millions of differences in them emitting warnings.
3822016-11-09T20:44:02 <wumpus> I tried with the gcc that comes with Ubuntu 16.04 (5.4.0) as well as clang 4.0 master git on Linux
3832016-11-09T20:44:04 <MarcoFalke> I think gcc is more aggressive and also complains if a local var shadows a function name (such as size() or one of our own functions)
3842016-11-09T20:44:41 <paveljanik> exactly!
3852016-11-09T20:45:26 <wumpus> haven't tested gcc 6.x, maybe that is uselessly agressive
3862016-11-09T20:47:08 *** jl2012 has quit IRC
3872016-11-09T20:47:09 <wumpus> http://stackoverflow.com/questions/2958457/gcc-wshadow-is-too-strict hah
3882016-11-09T20:47:28 *** jl2012 has joined #bitcoin-core-dev
3892016-11-09T20:51:02 *** btcdrak has joined #bitcoin-core-dev
3902016-11-09T20:55:26 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f445d886126c...fb156100f9b4
3912016-11-09T20:55:26 <bitcoin-git> bitcoin/master d8edf03 fanquake: Remove unused var UNLIKELY_PCT from fees.h
3922016-11-09T20:55:27 <bitcoin-git> bitcoin/master fb15610 Wladimir J. van der Laan: Merge #9111: Remove unused variable UNLIKELY_PCT from fees.h...
3932016-11-09T20:55:36 <bitcoin-git> [bitcoin] laanwj closed pull request #9111: Remove unused variable UNLIKELY_PCT from fees.h (master...remove-unused-unlikely-pct) https://github.com/bitcoin/bitcoin/pull/9111
3942016-11-09T21:06:35 *** LeMiner has quit IRC
3952016-11-09T21:07:26 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fb156100f9b4...faec09bc7f03
3962016-11-09T21:07:26 <bitcoin-git> bitcoin/master e5d682f jnewbery: Fix mininode version message format
3972016-11-09T21:07:27 <bitcoin-git> bitcoin/master faec09b Wladimir J. van der Laan: Merge #8894: [Testing] Include fRelay in mininode version messages...
3982016-11-09T21:07:35 <bitcoin-git> [bitcoin] dooglus opened pull request #9118: Remove requireGreater argment from TxConfirmStats::EstimateMedianVal() (master...remove-dead-code) https://github.com/bitcoin/bitcoin/pull/9118
3992016-11-09T21:11:29 *** crescendo has joined #bitcoin-core-dev
4002016-11-09T21:12:10 <bitcoin-git> [bitcoin] laanwj closed pull request #9048: [0.13 backport] Fix handling of invalid compact blocks (0.13...fix-invalid-cb-ban-0.13) https://github.com/bitcoin/bitcoin/pull/9048
4012016-11-09T21:12:30 <morcos> wumpus: is it critical to be doing all this clean up on fee estimation right now?
4022016-11-09T21:12:46 <morcos> i'd at least like a chance to think about it before you merge all these changes
4032016-11-09T21:12:57 <morcos> i understand those variables are unused now
4042016-11-09T21:13:18 <morcos> but they may still be useful functionality for further extension of the fee estimation code
4052016-11-09T21:14:39 <wumpus> morcos: no, imo it's not necessary, but I haven't heared you complain about it before
4062016-11-09T21:14:47 <wumpus> you could just NACK those pulls
4072016-11-09T21:15:04 <wumpus> if no one complains then dead code cleanups seems like a no-brainer
4082016-11-09T21:15:10 <morcos> i guess i just panicked b/c i saw one of them got merged before i even saw it
4092016-11-09T21:15:15 <morcos> within a 12 hours
4102016-11-09T21:15:20 <morcos> but that one actually was trivial
4112016-11-09T21:15:22 <wumpus> that was just a one-liner
4122016-11-09T21:15:23 <morcos> i will comment on the other
4132016-11-09T21:15:35 <morcos> i hadn't actually looked at the changes on either of them yet
4142016-11-09T21:15:53 <wumpus> also our usual policy is to remove dead code, we're using git to make it easy to bring back things if necessary
4152016-11-09T21:15:59 <morcos> but yes i'm in favor of the priority removal that was done of course, but the require greater logic was tricky to get right the first time
4162016-11-09T21:16:08 <morcos> i'd rather leave it until we're sure we won't want it again
4172016-11-09T21:16:20 <wumpus> I'll just stop merging things now, only caused problems today I feel :/
4182016-11-09T21:18:54 <wumpus> just too many pulls...
4192016-11-09T21:22:20 <morcos> wumpus: i'm impressed you keep up as well as you do.. my head is spinning... i started today trying to doing a posthumous ACK to the serialization cleanups, and i still haven't gotten around to looking at the 2nd commit.
4202016-11-09T21:25:08 <wumpus> I also have a harder and harder time keeping up
4212016-11-09T21:26:21 <morcos> i suppose its a good problem to have
4222016-11-09T21:26:48 <gmaxwell> wumpus: re the Wshadow warning, is it possible that the files aren't dirty when you change the flag so make isn't rebuilding them?
4232016-11-09T21:27:18 <gmaxwell> I was rebasing a branch from a distant version when I noticed the warngings, so my tree had been effectively make cleaned.
4242016-11-09T21:27:21 <bitcoin-git> [bitcoin] laanwj closed pull request #9118: Remove requireGreater argment from TxConfirmStats::EstimateMedianVal() (master...remove-dead-code) https://github.com/bitcoin/bitcoin/pull/9118
4252016-11-09T21:27:30 <wumpus> gmaxwell: no, I cleaned both the tree and the ccache, for both compilers
4262016-11-09T21:28:08 <wumpus> but I don't want to bother with the Wshadow warnings anymore, let's focus the rare time we have on more important things
4272016-11-09T21:31:02 <paveljanik> gmaxwell, can you please try http://tmp.janik.cz/q.diff?
4282016-11-09T21:31:14 <paveljanik> it should clear the nVersion from chain.h and others.
4292016-11-09T21:33:02 <gmaxwell> paveljanik: the only ones remaining with that are leveldb and bench/lockedpool.cpp
4302016-11-09T21:33:16 <paveljanik> gmaxwell, great!
4312016-11-09T21:33:41 <paveljanik> bench/lockedpool is clear IIRC.
4322016-11-09T21:33:46 <paveljanik> and leveldb is upstream 8)
4332016-11-09T21:33:49 <paveljanik> so fixed? ;-)
4342016-11-09T21:34:06 <gmaxwell> paveljanik: I see you're renaming local's to _local. That is a violation of the common convention in other codebases that function paramters get _prefixes.
4352016-11-09T21:34:08 <paveljanik> but I'll first retest on some rolling upstream Linux distro
4362016-11-09T21:34:35 <paveljanik> we used that even before and people agreed on it.
4372016-11-09T21:34:53 <paveljanik> some parts of the code use _, some _in, some In postfix..
4382016-11-09T21:35:15 <gmaxwell> Were we really using it for _local_ variables before, not just function parameters?
4392016-11-09T21:35:21 <paveljanik> yes
4402016-11-09T21:35:34 <paveljanik> I was inspired by it.
4412016-11-09T21:36:17 <paveljanik> but sometimes, it was better to rename the variables...
4422016-11-09T21:36:23 <paveljanik> and thus I did so
4432016-11-09T21:36:38 <paveljanik> e.g. data -> vData to follow the typeName conventions used
4442016-11-09T21:37:51 <paveljanik> I understand it is not sexy to read all those diffs though 8)
4452016-11-09T21:38:01 <paveljanik> but please be patient
4462016-11-09T21:38:54 <gmaxwell> paveljanik: for example, in 8808 src/streams.h
4472016-11-09T21:39:37 <paveljanik> yes, read -> _read.
4482016-11-09T21:39:44 <gmaxwell> you change read to _read it would be more ideomatic to change it to someghing like nBytes or bread or nread or something like that.
4492016-11-09T21:40:38 <paveljanik> no problem, just comment there and I will change it ;-)
4502016-11-09T21:41:20 <gmaxwell> When you make these updates are you checking to make sure the existing code wasn't buggy?
4512016-11-09T21:41:49 <paveljanik> sometimes. I even found some bugs, yes.
4522016-11-09T21:42:24 <gmaxwell> paveljanik: Good. I'll gladly leave some comments.
4532016-11-09T21:50:44 *** MarcoFalke has left #bitcoin-core-dev
4542016-11-09T22:04:48 *** Guyver2 has quit IRC
4552016-11-09T22:04:56 *** Guyver2 has joined #bitcoin-core-dev
4562016-11-09T22:05:12 <bitcoin-git> [bitcoin] UdjinM6 opened pull request #9120: bug: Missed one "return false" in recent refactoring in #9067 (master...fixExitCodesBitcoinTx) https://github.com/bitcoin/bitcoin/pull/9120
4572016-11-09T22:07:17 <paveljanik> gmaxwell, thank you!
4582016-11-09T22:12:12 *** belcher has joined #bitcoin-core-dev
4592016-11-09T22:26:45 <jtimon> morcos: no, I'm still getting my weird error on walletbackup even with #9058, really killall bitcoind ; rm -rf ./qa/cache ; doesn't seem enough
4602016-11-09T22:26:46 <gribble> https://github.com/bitcoin/bitcoin/issues/9058 | Fixes for p2p-compactblocks.py test timeouts on travis (#8842) by ryanofsky · Pull Request #9058 · bitcoin/bitcoin · GitHub
4612016-11-09T22:27:20 <morcos> jtimon: not for me right?
4622016-11-09T22:37:24 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4632016-11-09T22:43:18 <jtimon> reminder: I only get it by running all rpc tests, not running walletbackupt individually
4642016-11-09T22:43:48 <jtimon> you told me 9058 may help the other day, but it seems is unrelated :(
4652016-11-09T22:46:03 <jtimon> I'm locally getting errors on your branch, but I was getting them already and at this point I'm just doing something wrong with rpc tests somehow, so yeah, sorry for the too long explanation
4662016-11-09T22:51:01 <jtimon> btw, general thoughts on moving some fast extended tests to the common ones and maybe also some slow ones from the common ones to the extended ones?
4672016-11-09T22:56:19 <jtimon> re warnings you can still fix some shadowing even if you don't put the new flag yet
4682016-11-09T23:00:23 *** Guyver2 has quit IRC
4692016-11-09T23:37:20 *** davec has quit IRC
4702016-11-09T23:42:05 *** cryptapus has joined #bitcoin-core-dev
4712016-11-09T23:43:36 *** davec has joined #bitcoin-core-dev
4722016-11-09T23:45:20 <jtimon> I'm starting to think it may not be just be but actually something between 1adf82ac and faec09bc
4732016-11-09T23:46:09 *** cdecker has quit IRC
4742016-11-09T23:47:00 *** cryptapus has quit IRC
4752016-11-09T23:53:34 <jtimon> s/just be/just me/
4762016-11-09T23:57:58 *** btcdrak has quit IRC