--- Day changed Fri Feb 24 2017
00:00 < wumpus> jonasschnelli: that is a potential concern, however what happens in the RPC tests shouldn't affect test_bitcoin?
00:00 < jonasschnelli> wumpus: I meant the RPC unit tests... 
00:00 < wumpus> no valgrind errors in test_bitcoin?
00:00 < wumpus> ooh!
00:01 < jonasschnelli> look for rpc_togglenetwork
00:01 < jonasschnelli> rpc_tests.cpp
00:01 < jonasschnelli> Not sure if its related... we have added this a couple of weeks (or even months) ago
00:01 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds]     
00:02 < jonasschnelli> Here's my valgrind run: https://0bin.net/paste/2xS-7aRGhWA11BlS#uwUOiDB9X4h+puz6AxdtnWiMXF5KJlUhC-WFL8bCy4k
00:02 < jonasschnelli> This also frightens me: ==59692== Conditional jump or move depends on uninitialised value(s)
00:05 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:05 < gmaxwell> what version are you running it against those line number do not agree with my code here.
00:06 < jonasschnelli> 9949ebfa6a548260858df429f4d0e716e0a26065
00:06 < jonasschnelli> I think this is 0.14.0rc1
00:06 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
00:07 < jonasschnelli> my setup: ./configure --enable-zmq --enable-glibc-back-compat --enable-reduce-exports CPPFLAGS=-DDEBUG_LOCKORDER --with-incompatible-bdb
00:08 < jonasschnelli> (same as the failing travis setup)
00:08 < gmaxwell> oh geesh we have source files with the same name. bet that'll be fun for anyone trying to build with msvc.
00:09 < jonasschnelli> you mean the problem when we removed the rpc_ prefix and moved them into the rpc/ folder?
00:09 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
00:09 < gmaxwell> yea, at least last time I used it MSVC couldn't handle source files having the same name even if they were in different directories. :)
00:09 < jonasschnelli> My IDEs find by filename also doesn't like this
00:10 < jonasschnelli> We could have kept the rpc_ prefix even after moving them into the specific folder
00:12 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-aqtztorgytmaacne] has joined #bitcoin-core-dev     
00:12 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer]     
00:13 < gmaxwell> so in that rpc tests I don't see anything that sets up the conman object.  But if it's executing those objects it's not null. How is the g_conman setup in the tests?
00:13 < fanquake> jonasschnelli I can see the same results with valgrind
00:13 < jonasschnelli> TestingSetup() jas a g_connman = std::unique_ptr<CConnman>(new CConnman(0x1337, 0x1337)); // Deterministic randomness for tests.
00:13 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
00:14 < fanquake> https://0bin.net/paste/DLBX7+ZYaQ79TrRS#ACJ-Fp8c8aAZrLW2jDShhRMKbnTlxlnRJDkCRhXfpcI
00:15 < jonasschnelli> Thanks fanquake 
00:20 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
00:23 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds]     
00:28 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
00:28 -!- whphhg [whphhg@gateway/vpn/mullvad/x-aomatfcwowscsxcm] has joined #bitcoin-core-dev     
00:30 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
00:30 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
00:33 < cfields> https://github.com/theuni/bitcoin/commit/72aa3324bc69640937f2fda6a63634bcf1e8c6c1
00:33 < cfields> should fix the connman issue, though i seriously doubt that's the crasher
00:33 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer]     
00:33 < cfields> (thanks marcofalke for pointing that out earlier)
00:34 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
00:35 < cfields> i'll PR that in the morning
00:42 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
00:44 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 268 seconds]     
00:47 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 245 seconds]     
00:51 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
00:55 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev     
00:55 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
01:02 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
01:06 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
01:08 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
01:09 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
01:10 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
01:11 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
01:21 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
01:22 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/692c9eddba67...00285cece814
01:22 < bitcoin-git> bitcoin/master f81f0d0 Russell Yanofsky: Update sendfrom RPC help to correct coin selection misconception
01:22 < bitcoin-git> bitcoin/master 00285ce Wladimir J. van der Laan: Merge #9840: Update sendfrom RPC help to correct coin selection misconception...
01:22 < bitcoin-git> [bitcoin] laanwj closed pull request #9840: Update sendfrom RPC help to correct coin selection misconception (master...pr/fromacct) https://github.com/bitcoin/bitcoin/pull/9840
01:23 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
01:25 -!- go1111111 [~go1111111@c-24-18-220-198.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]     
01:34 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
01:37 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 255 seconds]     
01:42 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
01:44 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Read error: Connection reset by peer]     
01:44 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 255 seconds]     
01:51 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
01:53 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
01:54 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/00285cece814...dd6e0d630167
01:54 < bitcoin-git> bitcoin/master ef9f495 Marko Bencun: Trivial: fix comments referencing AppInit2...
01:54 < bitcoin-git> bitcoin/master dd6e0d6 Wladimir J. van der Laan: Merge #9833: Trivial: fix comments referencing AppInit2...
01:54 < bitcoin-git> [bitcoin] laanwj closed pull request #9833: Trivial: fix comments referencing AppInit2 (master...stalecomments) https://github.com/bitcoin/bitcoin/pull/9833
01:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:56 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
01:58 < paveljanik> FWIW - I'm not able to reproduce test_bitcoin failures on any of my machines (different unices) :-(
01:58 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds]     
02:03 < wumpus> darn
02:03 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
02:03 < bitcoin-git> [bitcoin] laanwj closed pull request #9846: doc: Small release notes fixups in the list of pulls (0.14...Mf1702-014doc) https://github.com/bitcoin/bitcoin/pull/9846
02:05 < wumpus> there seems to be nothing *special* in the config.log posted in #9850
02:05 < gribble> https://github.com/bitcoin/bitcoin/issues/9850 | test_bitcoin: /usr/include/boost/thread/pthread/recursive_mutex.hpp:104: boost::recursive_mutex::~recursive_mutex(): Assertion `!pthread_mutex_destroy() failed. · Issue #9850 · bitcoin/bitcoin · GitHub
02:05 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds]     
02:06 < wumpus> standard ubuntu 16.04 versions of everything
02:08 < wumpus> no arguments to configure
02:17 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
02:19 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 255 seconds]     
02:21 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-zrnathibqltmcxpf] has quit []     
02:21 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-rjpzsxtquqaaujet] has joined #bitcoin-core-dev     
02:22 < paveljanik> I suspect some travis issue
02:23 < paveljanik> (even if it was reproduced outside of it)
02:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-aqtztorgytmaacne] has quit [Quit: Connection closed for inactivity]     
02:24 < wumpus> I forgot something in my testing yesterday; the travis build passes, --enable-glibc-back-compat --enable-reduce-exports  and LDFLAGS=-static-libstdc++" . No difference in reproduction, though
02:25 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
02:26 < wumpus> I also test it faster now, launch test_bitcoin and kill it after a second (after all, the problem happens just before the Running ... line so there's no need to go all the way)
02:30 < wumpus> in any case it just works perfectly, every time, no matter what I do. Almost feels like travis is trolling us
02:31 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jlmimlsbsvmlhzls] has joined #bitcoin-core-dev     
02:35 < gmaxwell> "Why do the patterns of failuers seem to be spelling ascii digits? ...'wouldnt want to give yo..'"
02:36 < wumpus> hehe, yes that would be a giveaway
02:36 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
02:38  * wumpus threw DEBUG_LOCKORDER into the mix. No, that didn't help either
02:45 < wumpus> never felt so unhappy to see "*** No errors detected"
02:49 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
02:52 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
02:54 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
02:54 < wumpus> well, so much for trying to reproduce locally, going to try set up a trap for this on travis
03:05 < wumpus> ok my gdb script is working, this should work
03:10 < bitcoin-git> [bitcoin] laanwj opened pull request #9851: [do not merge] travis gdb parachute for #9825 (master...2017_02_travisissue) https://github.com/bitcoin/bitcoin/pull/9851
03:18 -!- Alina-malina_ [~Alina-mal@37.157.223.80] has joined #bitcoin-core-dev     
03:26 -!- Alina-malina_ [~Alina-mal@37.157.223.80] has quit [Changing host]     
03:26 -!- Alina-malina_ [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
03:28 -!- Alina-malina_ is now known as Alina-malina     
03:41 < bitcoin-git> [bitcoin] zcc0721 opened pull request #9852: Merge remote-tracking branch 'refs/remotes/bitcoin/master' (master...master) https://github.com/bitcoin/bitcoin/pull/9852
03:42 < bitcoin-git> [bitcoin] laanwj closed pull request #9852: Merge remote-tracking branch 'refs/remotes/bitcoin/master' (master...master) https://github.com/bitcoin/bitcoin/pull/9852
03:46 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
03:47 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
03:49 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dd6e0d630167...f19afdbfb4cb
03:49 < bitcoin-git> bitcoin/master dc222f8 Karl-Johan Alm: Trivial: Rephrase the definition of difficulty in the code.
03:49 < bitcoin-git> bitcoin/master f19afdb Wladimir J. van der Laan: Merge #9612: [trivial] Rephrase the definition of difficulty....
03:49 < bitcoin-git> [bitcoin] laanwj closed pull request #9612: [trivial] Rephrase the definition of difficulty. (master...clarify-difficulty) https://github.com/bitcoin/bitcoin/pull/9612
03:57 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]     
03:58 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds]     
04:00 < wumpus> wth, one of the builds in #9825 is rebuilding all the dependencies?
04:00 < gribble> https://github.com/bitcoin/bitcoin/issues/9825 | Intermittent FAIL: test/test_bitcoin in Travis · Issue #9825 · bitcoin/bitcoin · GitHub
04:01 < wumpus> eh  #9851
04:01 < gribble> https://github.com/bitcoin/bitcoin/issues/9851 | [do not merge] travis gdb parachute for #9825 by laanwj · Pull Request #9851 · bitcoin/bitcoin · GitHub
04:01 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Read error: Connection reset by peer]     
04:04 < wumpus> Everything that can go wrong is going wrong, man, it's hard to think of a more nightmarish way to debug things. Well maybe debugging the kernel for GPU cache issues wins by a bit :/
04:05 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
04:06 < wumpus> I'm going to cancel all other travis builds to give this one priority, sorry
04:08 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
04:10 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-tdjswpqodbvjcddl] has joined #bitcoin-core-dev     
04:11 < wumpus> ah the builds are starting, let's see what surprises await this time
04:11 < wumpus> NOOOOOOO don't start building ccache :(
04:30 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 240 seconds]     
04:41 < wumpus> cfields: what would be the best way to skip buildling of dependencies for a PR, for debugging?
04:43 < wumpus> I don't understand why all three builds of #9851 trigger a complete dependency rebuild, but this way it's not going to work, I need a fast iteration time to have any chance of reproducing the issue
04:43 < gribble> https://github.com/bitcoin/bitcoin/issues/9851 | [do not merge] travis gdb parachute for #9825 by laanwj · Pull Request #9851 · bitcoin/bitcoin · GitHub
04:45 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Read error: Connection timed out]     
04:47 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev     
04:47 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
04:49 < wumpus> oh not all three, just #3, which is the nowallet one. Could just remove that one.
04:49 < gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
04:50 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Max SendQ exceeded]     
04:51 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Remote host closed the connection]     
04:53 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev     
04:56 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Max SendQ exceeded]     
04:57 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev     
05:09 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
05:10 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-iftxkrupbolzykki] has quit [Ping timeout: 240 seconds]     
05:11 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-wixlumuzlnijkjnz] has joined #bitcoin-core-dev     
05:13 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Read error: Connection timed out]     
05:22 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
05:25 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Remote host closed the connection]     
05:38 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
05:43 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 260 seconds]     
05:47 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
05:49 -!- Cory [~Cory@unaffiliated/cory] has quit [Remote host closed the connection]     
05:53 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
05:58 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
06:04 -!- Cory [~Cory@unaffiliated/cory] has quit [Remote host closed the connection]     
06:07 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
06:12 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 240 seconds]     
06:16 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
06:18 -!- Cory [~Cory@unaffiliated/cory] has quit [Remote host closed the connection]     
06:18 < achow101> did the signed binary detached sigs come out yet?
06:27 < BlueMatt> wumpus: you could do it on your own personal fork?
06:27 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
06:30 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Remote host closed the connection]     
06:34 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
06:35 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
06:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2]     
06:37 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Remote host closed the connection]     
06:45 < jonasschnelli> Any idea why the LXC gitian initialization takes that long?
06:46 < jonasschnelli> Here it takes >5mins during "Upgrading system, may take a while"... seems to be very long
06:46 < jonasschnelli> (step between "install.log" and starting of "build.log")
06:51 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
06:52 -!- goksinen is now known as wudayoda     
06:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:56 -!- goksinen [~goksinen@mobile-107-107-58-207.mycingular.net] has joined #bitcoin-core-dev     
06:58 -!- goksinen is now known as wudayoda_     
07:00 -!- wudayoda_ [~goksinen@mobile-107-107-58-207.mycingular.net] has quit [Quit: Leaving]     
07:03 -!- Guest49686 [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev     
07:12 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
07:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
07:16 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds]     
07:30 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
07:36 < cfields> wumpus: note that DEBUG=1 is used for the crash case. That adds the extra bounds checking from libstdc++
07:40 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
07:40 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
07:41 < cfields> wumpus: as for rebuilding depends, the travis cache depends on the env vars set. So if you change an env var, it will create a new cache because it looks like a new build that it shouldn't clobber
07:42 < cfields> where "change" also includes adding/removing env vars
07:42 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has quit [Remote host closed the connection]     
07:45 -!- Guest91228 [~Cory@24-240-67-80.dhcp.mdsn.wi.charter.com] has joined #bitcoin-core-dev     
07:48 < cfields> gitian builders: sigs for v0.14.0rc2 are pushed
07:50 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
07:58 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]     
08:00 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
08:13 < wumpus> ah so the env vars are the secret :)
08:26 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
08:29 < bitcoin-git> [bitcoin] jnewbery opened pull request #9853: Fix error codes from various RPCs (master...fixerrorcodes) https://github.com/bitcoin/bitcoin/pull/9853
08:29 < bitcoin-git> [bitcoin] jnewbery closed pull request #9713: Fix error causes and messages in rpc/net.cpp (master...fixsetbanerrormessages) https://github.com/bitcoin/bitcoin/pull/9713
08:29 < bitcoin-git> [bitcoin] jnewbery closed pull request #9714: Return correct error codes from bumpfee() (master...bumpfeeerrormessages) https://github.com/bitcoin/bitcoin/pull/9714
08:34 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
08:39 < BlueMatt> so now that we have named args someone should probably do a pass and fix the million places that we reject args that are null even when they have a default value, I suppose?
08:41 < wumpus> BlueMatt: yes - null should be interpreted as the default value, on a call by call basis
08:42 < wumpus> I intend to get around to that for 0.15
08:46 < wumpus> in most cases it's trivial
08:46 < wumpus> there are a few such as getbalance that have slightly different functionality based on the number of arguments, some discussion will be needed there
08:51 -!- abpa [~abpa@96.82.80.25] has joined #bitcoin-core-dev     
09:06 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
09:17 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Remote host closed the connection]     
09:18 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
09:19 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
09:20 -!- moli_ [~molly@unaffiliated/molly] has quit [Remote host closed the connection]     
09:20 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
09:50 -!- handlex [~handlex@2804:14c:658f:4dc7:4c8c:c38b:a078:1268] has joined #bitcoin-core-dev     
10:03 -!- handlex [~handlex@2804:14c:658f:4dc7:4c8c:c38b:a078:1268] has quit [Quit: handlex]     
10:13 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev     
10:20 -!- handlex [~handlex@2804:14c:658f:4dc7:8515:ba5:149a:c1b4] has joined #bitcoin-core-dev     
10:30 -!- handlex [~handlex@2804:14c:658f:4dc7:8515:ba5:149a:c1b4] has quit [Quit: handlex]     
10:34 -!- harrymm [~wayne@104.222.140.110] has quit [Remote host closed the connection]     
10:38 -!- harrymm [~wayne@104.222.140.86] has joined #bitcoin-core-dev     
11:06 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:13 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
11:15 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds]     
12:13 -!- bsm117532 [~mcelrath@135.84.167.210] has quit [Killed (card.freenode.net (Nickname regained by services))]     
12:14 -!- bsm117532 [~mcelrath@135.84.167.210] has joined #bitcoin-core-dev     
12:53 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
12:55 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 260 seconds]     
12:55 -!- Guest49686 is now known as schmidty     
12:56 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
13:12 -!- go1111111 [~go1111111@2601:602:8802:78c0:ed70:9491:8420:5f8d] has joined #bitcoin-core-dev     
13:13 -!- bsm1175322 [~mcelrath@135.84.167.210] has joined #bitcoin-core-dev     
13:17 < sipa> i can't file an issue right now, but my RPi3 bitcoind OOMed, and marked a block invalid as a result
13:17 < sipa> that's very bad...
13:17 < sipa> on 0.14.0rc1
13:24 -!- e4xit_ [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
13:28 < cfields> sipa: yikes
13:28 < cfields> sipa: any idea where it oom'd?
13:29 -!- go1111111 [~go1111111@2601:602:8802:78c0:ed70:9491:8420:5f8d] has quit [Ping timeout: 255 seconds]     
13:59 -!- cysm [cysm@gateway/shell/elitebnc/x-ujjzqkgrohzzyppg] has quit [Ping timeout: 264 seconds]     
13:59 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 258 seconds]     
14:03 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev     
14:12 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer]     
14:13 -!- cysm [cysm@gateway/shell/elitebnc/x-ycnirleqyhbipejb] has joined #bitcoin-core-dev     
14:14 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]     
14:15 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 240 seconds]     
14:18 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]     
14:18 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
14:19 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
14:23 < sipa> cfields: #9854
14:23 < gribble> https://github.com/bitcoin/bitcoin/issues/9854 | Bitcoind 0.14.0rc1: OOM -> block marked invalid · Issue #9854 · bitcoin/bitcoin · GitHub
14:23 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev     
14:28 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 240 seconds]     
14:38 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev     
14:46 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jlmimlsbsvmlhzls] has quit [Ping timeout: 240 seconds]     
14:49 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rptksjmacbwnaipr] has joined #bitcoin-core-dev     
14:54 -!- limpkin [sid20909@gateway/web/irccloud.com/x-uhhzhmimicddsmaw] has quit [Ping timeout: 264 seconds]     
14:55 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-rjpzsxtquqaaujet] has quit [Ping timeout: 240 seconds]     
14:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rptksjmacbwnaipr] has quit [Read error: Connection reset by peer]     
15:01 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-eukcfgyuirfakgzn] has joined #bitcoin-core-dev     
15:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-sbgteexdmhdphkvl] has joined #bitcoin-core-dev     
15:05 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
15:05 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host]     
15:05 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
15:06 -!- limpkin [sid20909@gateway/web/irccloud.com/x-mlktsrczigrgkjly] has joined #bitcoin-core-dev     
15:10 < cfields> sipa: seems i just managed to bring down my dev box while testing a fix (forcing OOM). Hope you're happy :)
15:11 < cfields> woohoo, rescued
15:14 -!- jtimon [~quassel@199.116.72.155] has joined #bitcoin-core-dev     
15:16 < BlueMatt> cfields: so you have a fix? or should I go look into it?
15:17 < cfields> BlueMatt: yea, i have a patch ready. I'm uneasy about it though, so debate welcome
15:17 < cfields> sec     
15:18 < BlueMatt> k     
15:18 -!- jtimon [~quassel@199.116.72.155] has quit [Remote host closed the connection]     
15:22 < cfields> BlueMatt: see 9854
15:22 < BlueMatt> oh     
15:22 < BlueMatt> hmmmm, I like that
15:22 < BlueMatt> wait, does this apply to more than bad_alloc?
15:23 < cfields> no     
15:23 < gmaxwell> cfields: next time replace malloc with a wrapper. :P
15:23 < BlueMatt> if we can make it apply only to std::bad_alloc then I'm all for it (or is there a list of all the things this could apply to?)
15:23 < BlueMatt> lol     
15:23 < gmaxwell> BlueMatt: sipa pointed out the error to me earlier in private, my comment:
15:23 < gmaxwell> 11:55 <gmaxwell> God damnit. it really should not reject the block because of a fucking exception!
15:23 < cfields> gmaxwell: you mean new? :)
15:24 < gmaxwell> 11:55 <gmaxwell> I hate that we use exceptions for error handling in the seralization.
15:24 < gmaxwell> 11:56 <gmaxwell> maybe we can wrap the allocator so that failures kill the process.
15:24 < gmaxwell> cfields: well I mean the underlying libc function new calls, which is malloc. (same way tcmalloc replaces the allocator)
15:24 < cfields> gmaxwell: this isn't our exception. This is a c++ feature.
15:24 < cfields> gmaxwell: right, this overrides what happens when "new" fails. So this is essentially what you're asking for
15:25 < gmaxwell> cfields: no no: Our mistake is that a var int decode failure is an exception. Because of this we cannot wrap block processing with a catch * {tell user their hardware is befucked or someting bad happened}.
15:25 < cfields> gmaxwell: oh, i see what you mean
15:26 < gmaxwell> Which basically means that random programming errors that throw exceptions can cause blocks to be rejected intead of the node shutting down, which is exactly what produced the bdb locks as a fork rather than a brief DOS.
15:26 < BlueMatt> wait, ok, so has someone identified what actually happened here?
15:26 < gmaxwell> There are basically three states for block processing:  "I have a valid block", "I have an invalid block.", and "I notice that I am confused."  the latter should shut down without marking the block invalid.
15:26 < sipa> gmaxwell: i think you're overgeneralizing
15:27 < cfields> gmaxwell: i completely agree. but this is a specific case that can be easily detected
15:27 < sipa> gmaxwell: problems during deserialization shouldn't _ever_ cause a block to be marked invalid
15:27 < gmaxwell> yes, this one we can work around. But where is the next one? this is the second one of those btw.
15:27 < gmaxwell> Leveldb internal errors also used to do this to us.
15:27 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]     
15:27 < gmaxwell> Third if you count bdb's internal errors.
15:27 < cfields> gmaxwell: so let's fix that independently :)
15:27 < gmaxwell> I'm fine with your general fix approach for now.
15:27 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
15:28 < cfields> there's one gotcha there, though... prevector calls malloc directly
15:28 < gmaxwell> I am lamenting that C++ code randomly calls exceptions without documenting the possiblity clearly. And that we make use of exceptions to mark invalidity. Which means that random internal errors can mark invalidity.  And you all know I hate exceptions, so that bias is not in question. :)
15:29 < gmaxwell> cfields: why are you replacing new and not malloc? (I don't have a strong opinion, it's just a question)
15:29 < sipa> cfields: it could use new[] instead, i think
15:29 < sipa> gmaxwell: how do you replace malloc?
15:29 < gmaxwell> glibc has a specific override. But perhaps there is no portable way?
15:29 < sipa> you'd need to do it with link-time magic, and hope that libstdc++ doesn't bypass it somehow
15:29 < BlueMatt> I'm still confused, where do we use such exceptions to mark invalidity?
15:29 < sipa> BlueMatt: i don't know!
15:29 < sipa> we shouldn't!
15:30 < BlueMatt> yes, I dont see the specific issue here, yet
15:30 < gmaxwell> sipa: your logs showed we did exactly that.
15:30 < BlueMatt> gmaxwell: no they dont
15:30 < BlueMatt> "ERROR: ConnectBlock(): inputs missing/spent"
15:30 < cfields> BlueMatt: my take-away from the above was that if we didn't throw in deserialization, we could just wrap acceptblock and activatebestchain in try/catch(), and abort any time something's caught
15:30 < BlueMatt> that was after the bad_alloc
15:31 < cfields> gmaxwell: memory allocation failed, then the _next block_ was rejected
15:31 < BlueMatt> cfields: yes, and we should do that, probably still
15:31 < sipa> gmaxwell: my assumption is that the error _is_ caught somewhere, not passed up, and as a result a normal "fail" return value is returned, and a higher layer interprets that as invalid block
15:31 < sipa> gmaxwell: i don't think we have anywhere a direct "exception? mark invalid!" logic
15:31 < BlueMatt> sipa: script interpreter does
15:31 < BlueMatt> but thats it i believe
15:32 < BlueMatt> (in the debug log you posted I do not believe that was the error, either)
15:32 < gmaxwell> we do all over the place! we have a generic catch that returns false on functions that must be true for validity.
15:33 < BlueMatt> gmaxwell: we do?
15:33 < gmaxwell> Open up validation.cpp basically every catch in there does this.
15:33 < cfields> sipa: my take was that the block was accepted, but we didn't switch to the new tip, so the next block failed when looking up inputs
15:33 < BlueMatt> only script interpreter i believe
15:34 < gmaxwell> okay it's not as bad as I thought.
15:34 < sipa> did we in 0.14 introduce the SendRejectsAndCheckIfBanned(pfrom, connman) call in net_processing:2754 ?
15:34 < BlueMatt> well now that i check it is worse than I thought :p
15:34 < sipa> which before used to be inside the catch block?
15:34 < BlueMatt> some disk reads shit that probably should be smarter than it is
15:35 < BlueMatt> sipa: yes, and no, before it didnt exist
15:35 < BlueMatt> (was only in SendMessages)
15:35 < cfields> sipa: it's new, we used to only send rejects+ban from SendMessages()
15:36 < sipa> i see
15:38 < cfields> imo the throw happened somewhere around SetBestChain, it was just caught in ProcessMessages because that's the only place we do a generic catch(...)
15:38 < gmaxwell> BlueMatt: well I thought it was _every_ one of them, but I checked readblockfromdisk and it's not.
15:42 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 240 seconds]     
15:49 -!- jtimon [~quassel@199.116.72.155] has joined #bitcoin-core-dev     
15:53 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 240 seconds]     
15:53 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev     
15:56 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
16:02 < cfields> sipa: want me to PR that? Or you have something else in mind?
16:02 < BlueMatt> sipa: ok, here's a theory......"10:39:08 Prune:" is the prune called by AcceptBlock's FlushStateToDisk call (seems obvious given the Pre-allocating blk just above)....now, that flush call hit fDoFullFlush triggering a pcoinsTip->Flush(). OK, so now in CCoinsViewDB::BatchWrite we iterate over the entries in mapCoins, allocating memory for each one in the leveldb batch, erasing *AS WE GO*...at some point it ran out of memory, throwing 
16:02 < BlueMatt> bad_alloc and leaving pcoinsTip in an inconsistent state, but std::bad_alloc is not an std::runtime_error so the catch at the end of FlushStateToDisk didnt catch it. OK, phew, so now we go to connect the next block and fail to connect its inputs (without allocating new disk space). I /think/ that explains your debug.log without hand waving about hardware errors
16:04 -!- alpalp [~alpalp@2605:6000:f4ea:ff00:d027:3a17:6486:bfbd] has joined #bitcoin-core-dev     
16:04 -!- alpalp [~alpalp@2605:6000:f4ea:ff00:d027:3a17:6486:bfbd] has quit [Changing host]     
16:04 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev     
16:04 < sipa> BlueMatt: sounds like a plausible theory
16:04 < sipa> cfields: PR what?
16:04 < cfields> BlueMatt: that was my reading of it as well
16:05 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
16:05 < cfields> sipa: https://github.com/theuni/bitcoin/commit/28afe574567ba838d46959047282460dbab39b91
16:05 < sipa> if that's the problem (and that seems to become more plausible as dbcache gets set higher, as you get the duplication only at flush time)
16:05 < sipa> we should probably make the batch construction not erase things for ccoinscache
16:06 < BlueMatt> sipa: yes, an easy way to make this particular, very specific issue, less likely is to not erase as we go
16:06 < BlueMatt> ofc that means more memory usage, but...better than blowing up
16:08 < sipa> BlueMatt: alternatively, we could fail to flush, and still delete everything
16:08 < sipa> from the cache
16:08 < BlueMatt> sipa: hmm?
16:08 < sipa> ... and then reset pcoinsTip->hashBlock and chainActive to the last succesfully flushed block (which may be 1000s ago)
16:09 < BlueMatt> sipa: in that case we must AbortNode, I think?
16:09 < sipa> oh, absolutely
16:10 < sipa> but i'm worried we may not be able to to instantly abort (due to locks being held all over the place while the OOM occurs)
16:11 < BlueMatt> yea, I mean ideally we'd broaden the catch in FlushStateToDisk and use the AbortNode there
16:11 < BlueMatt> just this time dont let the coins map get into an inconsistent state
16:12 < sipa> cfields: looks good
16:13 < BlueMatt> cfields: oh, somehow I missed that that /is/ only for bad_alloc
16:13 < BlueMatt> yea, lets totally do that!
16:13 < cfields> <BlueMatt> wait, does this apply to more than bad_alloc?
16:13 < cfields> <cfields> no
16:13 < cfields> :)     
16:13 < BlueMatt> oh, reading comprehension fail
16:18 < cfields> sipa: want to switch prevector to new[] and ditch realloc()? Or call get_new_handler()() if they return null?
16:18 < cfields> (or just leave it alone and let something write to 0 :p)
16:18 < sipa> cfields: just switch it to new[]
16:18 < cfields> ok     
16:18 < BlueMatt> it would suck to drop realloc?
16:19 < BlueMatt> just assert(new_ptr)
16:19 < sipa> how often does realloc actually help?
16:20 < BlueMatt> no idea, but the difference between get_new_handler()() and assert(new_ptr) is minimal
16:20 < sipa> well i don't like making prevector assume that OOMs are fatal
16:20 < sipa> that's something application level
16:21 < BlueMatt> sipa: yea, and in our application they always are :p
16:22 < sipa> still, it's nicer to have that knowledge in only one place
16:26 < BlueMatt> sipa: internet says realloc is useful, though in our usage of prevector its likely not super noticeable
16:26 < BlueMatt> so I'm fine with whatever
16:30 < sipa> BlueMatt: oh, i just realized... calling get_new_handler()() in prevector doesn't imply it's going to fail
16:31 < BlueMatt> huh? you mean doesnt imply its going to std::terminate instead of throwing or so?
16:31 < sipa> yes     
16:32 < sipa> so, i don't care.
16:32 < BlueMatt> ok, if you prefer that, do that
16:41 < bitcoin-git> [bitcoin] jtimon opened pull request #9855: RPC: Use integer satoshis instead BTC with decimals (master...0.15-rpc-satoshis) https://github.com/bitcoin/bitcoin/pull/9855
16:48 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-eukcfgyuirfakgzn] has quit [Quit: Connection closed for inactivity]     
16:54 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:e1f0:f5b8:653b:5575] has quit [Quit: .]     
16:56 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:e84b:2ab3:cc65:e335] has joined #bitcoin-core-dev     
16:56 -!- gk_-1wm_- [~su@50.118.213.31] has joined #bitcoin-core-dev     
16:56 -!- gk_-1wm_- [~su@50.118.213.31] has left #bitcoin-core-dev []     
17:00 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
17:01 -!- abpa [~abpa@96.82.80.25] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:01 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
17:17 -!- bsm1175322 [~mcelrath@135.84.167.210] has quit [Ping timeout: 260 seconds]     
17:18 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-zuzkitkercprdfqk] has quit []     
17:18 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-kicibfzlmvjvtssf] has joined #bitcoin-core-dev     
17:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
17:30 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
17:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:35 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 240 seconds]     
17:39 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
17:56 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 260 seconds]     
17:58 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
18:11 -!- jtimon [~quassel@199.116.72.155] has quit [Remote host closed the connection]     
18:20 -!- gk_-1wm [~su@209.73.151.42] has joined #bitcoin-core-dev     
18:20 -!- gk_-1wm [~su@209.73.151.42] has left #bitcoin-core-dev []     
18:34 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
18:36 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Client Quit]     
18:39 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds]     
18:43 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]     
18:44 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-dlcwxtutegzbjliz] has joined #bitcoin-core-dev     
18:57 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 240 seconds]     
18:58 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
19:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
19:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
19:08 -!- alpalp [~alpalp@2605:6000:f4ea:ff00:d027:3a17:6486:bfbd] has joined #bitcoin-core-dev     
19:08 -!- alpalp [~alpalp@2605:6000:f4ea:ff00:d027:3a17:6486:bfbd] has quit [Changing host]     
19:08 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev     
19:35 < sipa> cfields, BlueMatt: crap, it seems i reported this exact same bug a year ago already...
19:59 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
20:01 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Remote host closed the connection]     
20:06 < cfields> sipa: heh. Well, at least we can get it in for 0.14
20:06 < cfields> sipa: does that mean it takes 1+ years to sync your rpi? :)
20:10 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]     
20:12 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev     
20:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-sbgteexdmhdphkvl] has quit [Quit: Connection closed for inactivity]     
20:18 < sipa> cfields: it's a new one
20:18 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Remote host closed the connection]     
20:18 < sipa> it took 2 days to sync to the point where it was
20:18 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev     
20:29 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds]     
20:31 -!- dodomojo [~goksinen@2604:2000:c591:8400:c43b:79b0:dec0:1f6d] has joined #bitcoin-core-dev     
20:43 -!- dodomojo [~goksinen@2604:2000:c591:8400:c43b:79b0:dec0:1f6d] has quit [Remote host closed the connection]     
20:49 -!- dodomojo [~goksinen@2604:2000:c591:8400:99e3:120c:9c7c:d6dc] has joined #bitcoin-core-dev     
20:49 -!- dodomojo [~goksinen@2604:2000:c591:8400:99e3:120c:9c7c:d6dc] has quit [Remote host closed the connection]     
21:06 < cfields> sipa: i have no clue how representative the CCheckQueueSpeedPrevectorJob bench is, but there's a noticible difference when switching to new[] and dropping realloc
21:07 < cfields> sipa: for the sake of being conservative this late in the release cycle, i think get_new_handler()() is likely to have much less impact
21:10 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #bitcoin-core-dev     
21:12 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
21:14 -!- roasbeef_ [~root@104.131.26.124] has joined #bitcoin-core-dev     
21:14 -!- davec__ [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev     
21:14 -!- gmaxwell_ [gmaxwell@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev     
21:14 -!- AdrianG_ [~User@45.ip-158-69-201.net] has joined #bitcoin-core-dev     
21:14 -!- wump [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev     
21:16 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 260 seconds]     
21:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
21:16 -!- jamoes [~cretwich@104.193.170-247.PUBLIC.monkeybrains.net] has quit [Ping timeout: 260 seconds]     
21:16 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 260 seconds]     
21:16 -!- Aleph0 [~User@unaffiliated/amphetamine] has quit [Ping timeout: 260 seconds]     
21:16 -!- haakonn [~haakonn@pdpc/supporter/active/haakonn] has quit [Ping timeout: 260 seconds]     
21:16 -!- murchandamus [~murchghos@ghostdub.de] has quit [Ping timeout: 260 seconds]     
21:16 -!- adiabat [~adiabat@67.205.158.84] has quit [Ping timeout: 260 seconds]     
21:16 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 260 seconds]     
21:16 -!- goregrin1 [~goregrind@unaffiliated/goregrind] has quit [Ping timeout: 260 seconds]     
21:16 -!- Guest74039 [~mr_burdel@bounce.cryptolabs.net] has quit [Ping timeout: 260 seconds]     
21:16 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 260 seconds]     
21:16 -!- _mn3monic [~guido@176.9.68.68] has quit [Ping timeout: 240 seconds]     
21:16 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 240 seconds]     
21:16 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 240 seconds]     
21:16 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 240 seconds]     
21:16 -!- so [~so@unaffiliated/so] has quit [Ping timeout: 240 seconds]     
21:16 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
21:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]     
21:16 -!- waxwing [~waxwing@185.65.135.88] has quit [Ping timeout: 240 seconds]     
21:16 -!- gluytium_ [U2FsdGVkX1@ma.sdf.org] has quit [Ping timeout: 240 seconds]     
21:16 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
21:16 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 240 seconds]     
21:16 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
21:16 -!- so_ [~so@unaffiliated/so] has joined #bitcoin-core-dev     
21:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
21:17 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev     
21:17 -!- waxwing [~waxwing@185.65.135.88] has joined #bitcoin-core-dev     
21:17 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
21:17 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev     
21:17 -!- gmaxwell_ [gmaxwell@mf4-xiph.osuosl.org] has quit [Changing host]     
21:17 -!- gmaxwell_ [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev     
21:17 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
21:17 -!- gmaxwell_ is now known as gmaxwell     
21:18 -!- adiabat [~adiabat@67.205.158.84] has joined #bitcoin-core-dev     
21:18 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
21:18 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
21:18 -!- jamoes [~cretwich@104.193.170-247.PUBLIC.monkeybrains.net] has joined #bitcoin-core-dev     
21:19 -!- gluytium [U2FsdGVkX1@ma.sdf.org] has joined #bitcoin-core-dev     
21:19 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:20 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 245 seconds]     
21:21 -!- haakonn [~haakonn@146.185.155.218] has joined #bitcoin-core-dev     
21:21 -!- haakonn is now known as Guest48161     
21:24 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev     
21:29 < sipa> cfields: ack
21:30 < bitcoin-git> [bitcoin] theuni opened pull request #9856: Terminate immediately when allocation fails (master...bad_alloc_terminate2) https://github.com/bitcoin/bitcoin/pull/9856
21:32 < cfields> damn fanquake, you're fast!
21:35 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
21:40 -!- fanquake1 [~fanquake@203-59-110-1.dyn.iinet.net.au] has joined #bitcoin-core-dev     
21:41 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Ping timeout: 260 seconds]     
21:41 -!- Guest48161 [~haakonn@146.185.155.218] has quit [Ping timeout: 260 seconds]     
21:41 -!- so_ [~so@unaffiliated/so] has quit [Ping timeout: 260 seconds]     
21:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
21:42 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
21:42 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
21:42 -!- so [~so@unaffiliated/so] has joined #bitcoin-core-dev     
21:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
21:46 -!- haakonn_ [~haakonn@146.185.155.218] has joined #bitcoin-core-dev     
21:59 < cfields> sipa: well i guess that discussion has been rendered moot. assert for 0.14, and do an efficient specialized unsigned char* prevector for master?
21:59 < sipa> cfields: ok
22:20 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
22:54 -!- roasbeef_ is now known as roasbeef     
23:00 -!- dermoth [~thomas@dsl-216-221-55-141.mtl.contact.net] has quit [Read error: Connection reset by peer]     
23:01 -!- dermoth [~thomas@dsl-216-221-55-141.mtl.contact.net] has joined #bitcoin-core-dev     
23:09 -!- _mn3monic [~guido@176.9.68.68] has joined #bitcoin-core-dev     
23:12 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
23:15 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 255 seconds]     
23:17 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds]     
23:20 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
23:36 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
23:45 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer]     
23:46 < wump> bah, #9856 is really ugly :/
23:46 < gribble> https://github.com/bitcoin/bitcoin/issues/9856 | Terminate immediately when allocation fails by theuni · Pull Request #9856 · bitcoin/bitcoin · GitHub
23:46 -!- wump is now known as wumpus     
23:47 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
23:48 -!- fanquake1 [~fanquake@203-59-110-1.dyn.iinet.net.au] has quit [Quit: Leaving.]     
23:52 < wumpus> I understand wanting to terminate immediately on a memory error in some cases, but can't you just catch the exception at some point instead of registereing a global handler?
23:52 < sipa> wumpus: the problem is exactly that it is being caught... and then we continue in an inconsistent state
23:52 < wumpus> well then crash the program at the catch site!
23:53 < sipa> that's what this does
23:53 < sipa> tell the program to crash whenever new fails
23:53 < wumpus> no, this uses some poorly documented feature of c++ to change a global callback for every failed allocation
23:53 < wumpus> instead of just in the consensus code or wherever it is actually dangerous
23:55 < wumpus> some allocation errors, either in bitcoin itself or in libraries may actually be recoverable, and they would now cause a crash
23:56 < sipa> oh, sure, longer term i think we can find something more specific
23:56 < sipa> but as long as we have "catch std::exception& e" everywhere, which catches everything, that's pretty hard
23:56 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer]     
23:56 < wumpus> I think this is a bad direction to go in with the code base
23:56 < wumpus> shoudln't we be addressing that then?
23:57 < sipa> in 0.14?
23:57 -!- nohup [4445a482@gateway/web/freenode/ip.68.69.164.130] has joined #bitcoin-core-dev     
23:57 < wumpus> for 0.14 this is ok, but this is a PR to master
23:58 < sipa> hmm, you think this should go in just 0.14?
23:58 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
23:58 < wumpus> the way the PR is now? yes, I think so. This just too aspecific an hack
23:58 < sipa> i think terminating when OOM is a very reasonable thing, and certainly more reasonable than trying to continuing
23:59 < wumpus> I think terminating on OOM in select cases is a reasonable thing