1 2016-08-30 02:18:52	0|luke-jr|9mo old said her first non-mama/papa word: "dot" [dot dot]
  2 2016-08-30 03:06:09	0|GitHub7|[13bitcoin] 15isle2983 opened pull request #8625: [doc] - clarify statement about parallel jobs in rpc-tests.py (06master...06rpcTestsDoc) 02https://github.com/bitcoin/bitcoin/pull/8625
  3 2016-08-30 03:25:17	0|jeremyrubin|luke-jr: ls
  4 2016-08-30 03:25:23	0|jeremyrubin|oops
  5 2016-08-30 03:31:48	0|isle2983|usually they start with 'grep' before getting into directory navigation...
  6 2016-08-30 03:35:29	0|luke-jr|jeremyrubin: ls: cannot open directory .: Transport endpoint is not connected
  7 2016-08-30 05:51:01	0|jeremyrubin|luke-jr: I was going to ask you a question because I thought it was something you had worked on, but it wasn't. Forgot to switch tabs before typing. At least I wasn't sudo'ing ;)
  8 2016-08-30 05:51:15	0|luke-jr|:P
  9 2016-08-30 05:51:51	0|jeremyrubin|ANyways; what I was going to ask generally is about how std::thread is used currently in core
 10 2016-08-30 05:52:04	0|jeremyrubin|I can't seem to get it to properly link or something in wine
 11 2016-08-30 05:52:12	0|jeremyrubin|(in use on my own code)
 12 2016-08-30 05:52:30	0|jeremyrubin|but on master it is already in use in httpserver.h
 13 2016-08-30 06:02:06	0|GitHub173|[13bitcoin] 15netsafe opened pull request #8626: Berkeley DB v6 compatibility fix (06master...06netsafe-patch-1) 02https://github.com/bitcoin/bitcoin/pull/8626
 14 2016-08-30 06:06:47	0|GitHub184|13bitcoin/06master 141467561 15isle2983: [doc] - clarify statement about parallel jobs in rpc-tests.py
 15 2016-08-30 06:06:47	0|GitHub184|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/89de1538ce1f...c01a6c48b982
 16 2016-08-30 06:06:48	0|GitHub184|13bitcoin/06master 14c01a6c4 15MarcoFalke: Merge #8625: [doc] - clarify statement about parallel jobs in rpc-tests.py...
 17 2016-08-30 06:06:57	0|GitHub194|[13bitcoin] 15MarcoFalke closed pull request #8625: [doc] - clarify statement about parallel jobs in rpc-tests.py (06master...06rpcTestsDoc) 02https://github.com/bitcoin/bitcoin/pull/8625
 18 2016-08-30 11:38:02	0|GitHub114|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c01a6c48b982...7b9889586501
 19 2016-08-30 11:38:03	0|GitHub114|13bitcoin/06master 14498d8da 15Andrew Chow: Check for OSX SDK
 20 2016-08-30 11:38:03	0|GitHub114|13bitcoin/06master 14eda4cfb 15Andrew Chow: Create an easy to use gitian building script...
 21 2016-08-30 11:38:04	0|GitHub114|13bitcoin/06master 146ffd6b4 15Andrew Chow: Create option to detach sign gitian builds and not commit the files in the script...
 22 2016-08-30 11:38:13	0|GitHub123|[13bitcoin] 15laanwj closed pull request #8566: Easy to use gitian building script (06master...06gitian-build-script) 02https://github.com/bitcoin/bitcoin/pull/8566
 23 2016-08-30 11:39:04	0|GitHub4|13bitcoin/06master 14203f212 15Pieter Wuille: Reduce default number of blocks to check at startup
 24 2016-08-30 11:39:04	0|GitHub4|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7b9889586501...2b23dbaee5b8
 25 2016-08-30 11:39:05	0|GitHub4|13bitcoin/06master 142b23dba 15Wladimir J. van der Laan: Merge #8611: Reduce default number of blocks to check at startup...
 26 2016-08-30 11:39:14	0|GitHub82|[13bitcoin] 15laanwj closed pull request #8611: Reduce default number of blocks to check at startup (06master...06fastcheck) 02https://github.com/bitcoin/bitcoin/pull/8611
 27 2016-08-30 11:40:20	0|jonasschnelli|What does "2016-08-29 20:22:53 socket send error Bad file descriptor (9)" mean? Running out of file descriptors?
 28 2016-08-30 11:41:41	0|jonasschnelli|One of my local node ran into this over night
 29 2016-08-30 11:46:42	0|wumpus|I don't think it's that, '9' isn't really a high number
 30 2016-08-30 11:46:50	0|wumpus|could be a use-after-close of some kind
 31 2016-08-30 11:47:01	0|jonasschnelli|It resulted in a shutdown at least
 32 2016-08-30 11:47:27	0|jonasschnelli|Also has bad allocs on the same machine.. could be memory related, though, its a brand new computer (means nothing, i know)
 33 2016-08-30 11:47:52	0|wumpus|ugh :/
 34 2016-08-30 11:48:02	0|jonasschnelli|DDR3L ram
 35 2016-08-30 11:48:10	0|wumpus|yes, memory corruption could definitely result in this, maybe the fd field was overwritten
 36 2016-08-30 11:48:40	0|wumpus|what do you exactly mean by 'bad allocs'?
 37 2016-08-30 11:49:41	0|jonasschnelli|bitcoind crashed with a std::expection bad alloc (I don't have the exact output right now)
 38 2016-08-30 11:50:22	0|jonasschnelli|EXCEPTION: St9bad_alloc
 39 2016-08-30 11:50:22	0|jonasschnelli|Here we go:
 40 2016-08-30 11:50:22	0|wumpus|that's running out of memory, not memory corruption
 41 2016-08-30 11:50:31	0|jonasschnelli|std::bad_alloc
 42 2016-08-30 11:50:32	0|jonasschnelli|bitcoin in ProcessMessages()
 43 2016-08-30 11:50:38	0|jonasschnelli|hmm....
 44 2016-08-30 11:50:47	0|wumpus|(well it can be memory corruption if the heap's administractive structures are corrupted, however that much more likely results in a segmentation fault)
 45 2016-08-30 11:50:50	0|jonasschnelli|free -h --> total 16GB
 46 2016-08-30 11:51:08	0|wumpus|strange. Does it have swap enabled?
 47 2016-08-30 11:51:11	0|jonasschnelli|Headless debian with only bitcoind running..
 48 2016-08-30 11:52:02	0|wumpus|swap is extrememly important in Linux, even if you have enough memory, otherwise (AFAIK) it won't overcommit virtual memory and such
 49 2016-08-30 11:52:16	0|jonasschnelli|"free" tells me, mem: Total, 15GB, used 2.7GB (restarted node with -dbcache=4000), Swap: total 17GB, used 0GB
 50 2016-08-30 11:52:30	0|wumpus|okay, that's not it then
 51 2016-08-30 11:52:37	0|wumpus|really strange
 52 2016-08-30 11:52:44	0|jonasschnelli|The machine has 16GB physical memory... I don't think it ran out of memory
 53 2016-08-30 11:52:50	0|jonasschnelli|I keep en eye on that
 54 2016-08-30 11:52:59	0|wumpus|did you change dbcache?
 55 2016-08-30 11:53:20	0|jonasschnelli|Yes. Always ran with -dbache=4000
 56 2016-08-30 11:53:28	0|jonasschnelli|But codewise its pure master
 57 2016-08-30 11:53:34	0|jonasschnelli|at a5bb6387f751e630c329f34cac2d38bffa8ff9cf
 58 2016-08-30 11:53:45	0|wumpus|ok... no, that won't be the issue I think
 59 2016-08-30 11:57:22	0|jonasschnelli|Heres the debug log: http://paste.ubuntu.com/23111528/
 60 2016-08-30 11:57:39	0|jonasschnelli|Line 839 is the std::bad_alloc
 61 2016-08-30 11:57:50	0|jonasschnelli|then there are some socket send error Bad file descriptor (9)
 62 2016-08-30 11:58:21	0|jonasschnelli|Really strange the "Misbehaving: 85.214.213.91:8333 (0 -> 100) BAN THRESHOLD EXCEEDED" ... I hope its not an exploit.
 63 2016-08-30 12:01:21	0|wumpus|well I think the bad_alloc causes that rejection/banning
 64 2016-08-30 12:01:35	0|wumpus|it's unfortunate that we don't know which exact allocation failed
 65 2016-08-30 12:03:08	0|wumpus|apparently it's somewhere in the ConnectBlock() inputs logic
 66 2016-08-30 12:04:42	0|wumpus|0000000000000000243ecc39a5c110fea174e34e4a2d00b5f2038ab2e2f5cf70  is the valid block at height 322006 - so if it was an exploit, it's not by sending a corrupted block
 67 2016-08-30 12:05:03	0|wumpus|kind of bad that a bad_alloc causes block rejection though
 68 2016-08-30 12:05:22	0|wumpus|after restarting you probably had to explicitly re-verify the block?
 69 2016-08-30 12:06:31	0|jonasschnelli|wumpus: I had to reindex at some point... IIRC, I had to do it afterwards.
 70 2016-08-30 12:06:56	0|jonasschnelli|But maybe the reindex was on a different datadir/run
 71 2016-08-30 12:07:18	0|jonasschnelli|At L912 is looks after a valid restart without reindex
 72 2016-08-30 12:30:11	0|wumpus|travis is misbehaving badly again: https://github.com/bitcoin/bitcoin/issues/8532#issuecomment-243419143
 73 2016-08-30 12:30:36	0|wumpus|I doubt it can be the result of any of today's commits
 74 2016-08-30 12:50:36	0|sipa|wumpus: i think 9 may be the errno code?
 75 2016-08-30 12:54:10	0|wumpus|sipa: ah, yes, probably
 76 2016-08-30 15:27:18	0|jonasschnelli|The node above stalled at height 322005
 77 2016-08-30 15:27:27	0|jonasschnelli|last 3000 lines of debug log: http://paste.ubuntu.com/23112229/
 78 2016-08-30 15:27:34	0|jonasschnelli|getblockchaininfo: http://paste.ubuntu.com/23112227/
 79 2016-08-30 15:28:21	0|jonasschnelli|No new logprinf since 2h
 80 2016-08-30 15:28:38	0|jonasschnelli|But bitcoind is running: jonassc+  1000 89.6  8.0 1614436 1331624 pts/1 SLl+ 13:40 204:02 ./src/bitcoind --dbcache=4000
 81 2016-08-30 15:28:47	0|jonasschnelli|deadlock?
 82 2016-08-30 15:29:29	0|sipa|jonasschnelli: getchaintips
 83 2016-08-30 15:29:34	0|sipa|jonasschnelli: getpeerinfo
 84 2016-08-30 15:30:21	0|jonasschnelli|sipa: http://paste.ubuntu.com/23112236/
 85 2016-08-30 15:30:38	0|jonasschnelli|peerinfo: http://paste.ubuntu.com/23112238
 86 2016-08-30 15:32:05	0|jonasschnelli|attached gdb and bt is: http://paste.ubuntu.com/23112247/
 87 2016-08-30 15:32:50	0|jonasschnelli|wait.. thats useless. nm
 88 2016-08-30 15:33:18	0|jonasschnelli|RPC server works.. but network layer seems to be dead
 89 2016-08-30 15:34:12	0|sipa|jonasschnelli: thread apply all bt
 90 2016-08-30 15:34:27	0|jonasschnelli|http://pastebin.com/sWbcbz8U
 91 2016-08-30 15:34:27	0|jonasschnelli|sipa: was just doing this:
 92 2016-08-30 15:38:16	0|jtimon|now that we're C++11, what should I use instead of boost::scoped_ptr<> ?
 93 2016-08-30 15:40:32	0|sipa|std::unique_ptr
 94 2016-08-30 15:41:59	0|sipa|jonasschnelli: what is on net.cpp:1909
 95 2016-08-30 15:42:23	0|jonasschnelli|messageHandlerCondition.timed_wait(lock, boost::posix_time::microsec_clock::universal_time() + boost::posix_time::milliseconds(100));
 96 2016-08-30 15:42:46	0|sipa|i don't see any deadlock
 97 2016-08-30 15:42:52	0|sipa|or any lock at all, even
 98 2016-08-30 15:42:58	0|jonasschnelli|sipa: https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1909
 99 2016-08-30 15:57:16	0|jonasschnelli|Is there a reason why a peer request headers and compact blocks (sendheaders and sendcmpct) to nodes not signaling NODE_NETWORK?
100 2016-08-30 15:58:06	0|jonasschnelli|I guess an SPV node at 70014 can just ignore those..
101 2016-08-30 16:53:53	0|jtimon|sipa thanks!
102 2016-08-30 17:33:10	0|sipa|jonasschnelli: read the bip
103 2016-08-30 17:33:18	0|sipa|it explicitly explains that :)
104 2016-08-30 18:08:22	0|jonasschnelli|sipa: Thanks. I should do that.
105 2016-08-30 18:34:10	0|jeremyrubin|Can anyone run `make bench` on wine 32 bit build?
106 2016-08-30 18:36:24	0|cfields|jeremyrubin: i can in a little bit
107 2016-08-30 18:36:57	0|jeremyrubin|kk thanks
108 2016-08-30 18:46:15	0|cfields|jeremyrubin: actually, "teach a man to fish" and all that... :)
109 2016-08-30 18:46:41	0|cfields|jeremyrubin: have you tried building/running for win32?
110 2016-08-30 18:50:53	0|jeremyrubin|cfields: yes
111 2016-08-30 18:51:16	0|cfields|jeremyrubin: you had issues, or just want to compare results?
112 2016-08-30 18:51:37	0|jeremyrubin|cfields: wine: Unhandled page fault on read access to 0x00000004 at address 0x6117a9 (thread 0009), starting debugger...
113 2016-08-30 18:52:01	0|jeremyrubin|cfields: errors. Playing around with things it seems to be some kind of link time issue I suspect
114 2016-08-30 18:53:02	0|cfields|jeremyrubin: errors running? or running under gdb? 'cause wine+gdb is a different beast :)
115 2016-08-30 18:54:08	0|jeremyrubin|cfields: there are two main issues. The first is the sys/time.h depends. I removed that for a std::chrono solution (can send you code) then, removing all test code, and by removing all the boost dependencies (replacing with standard way), I can run just the benchmarking framework.
116 2016-08-30 18:54:20	0|jeremyrubin|cfields: not under gdb
117 2016-08-30 18:54:56	0|jeremyrubin|cfields: adding the benchmarks back I can run again, so i'm doing a "bisect" on which of the benchmarks is causing the loading fault now, but I think it's link time because it doesn't even run
118 2016-08-30 18:55:10	0|jeremyrubin|cfields: I tried adding "-static" to LDFLAGS
119 2016-08-30 18:55:47	0|cfields|jeremyrubin: win32 builds are already static
120 2016-08-30 18:56:38	0|cfields|jeremyrubin: i'm afraid i'm missing some context, though. Does the current bench code not work in win32?
121 2016-08-30 18:57:06	0|jeremyrubin|cfields: I don't think so; let me test on master
122 2016-08-30 18:57:45	0|jeremyrubin|cfields: where can I see the static flags? I don't think they're set for bench
123 2016-08-30 18:58:03	0|cfields|jeremyrubin: ah, ok
124 2016-08-30 18:58:20	0|cfields|jeremyrubin: they're kinda a maze, sec
125 2016-08-30 18:58:21	0|jeremyrubin|cfields: `bench_bench_bitcoin_LDFLAGS = $(RELDFLAGS) $(AM_LDFLAGS) $(LIBTOOL_APP_LDFLAGS)`
126 2016-08-30 18:58:30	0|jeremyrubin|in Makefile.bench.include
127 2016-08-30 18:58:50	0|cfields|jeremyrubin: IIRC it's the LIBTOOL_APP_LDFLAGS that sets static
128 2016-08-30 18:59:04	0|jeremyrubin|in Makefile.test.include `test_test_bitcoin_LDFLAGS = $(RELDFLAGS) $(AM_LDFLAGS) $(LIBTOOL_APP_LDFLAGS) -static`
129 2016-08-30 18:59:12	0|cfields|AX_CHECK_LINK_FLAG([[-static]],[LIBTOOL_APP_LDFLAGS="$LIBTOOL_APP_LDFLAGS -all-static"])
130 2016-08-30 18:59:12	0|cfields|# In libtool-speak, it's -all-static.
131 2016-08-30 18:59:12	0|cfields|# -static is interpreted by libtool, where it has a different meaning.
132 2016-08-30 19:00:32	0|jeremyrubin|so as a minimal example; I'm failing with only the example bench included. I'm running on my branch, but let me try on master (I shouldn't have any changes that affect that tho)
133 2016-08-30 19:01:12	0|cfields|ok. trying here too.
134 2016-08-30 19:01:25	0|cfields|you're building with depends?
135 2016-08-30 19:01:48	0|cfields|or is that why you hacked it to be dependency-less?
136 2016-08-30 19:02:03	0|jeremyrubin|I'm building by this:
137 2016-08-30 19:02:45	0|jeremyrubin|(well, whatever it says in doc/build-windows)
138 2016-08-30 19:02:58	0|cfields|ok
139 2016-08-30 19:03:15	0|jeremyrubin|cd depends; make HOST=i686-w64-mingw32 -j4; cd ..; ./configure --prefix=`pwd`/depends/i686-w64-mingw32; make
140 2016-08-30 19:03:49	0|cfields|right
141 2016-08-30 19:04:42	0|jeremyrubin|also you may want this:
142 2016-08-30 19:04:48	0|jeremyrubin|std::chrono::duration<double> result {std::chrono::system_clock::now().time_since_epoch()};
143 2016-08-30 19:04:53	0|jeremyrubin|return result.count();
144 2016-08-30 19:05:14	0|jeremyrubin|for bench.cpp gettimedouble
145 2016-08-30 19:08:25	0|jeremyrubin|(not sure if the sys/time.h include is problematic)
146 2016-08-30 19:08:43	0|cfields|yea, we should aim to nuke those.
147 2016-08-30 19:09:34	0|jeremyrubin|Yeah I can separately PR nuking them; pretty easy to remove that & the boost depends as well
148 2016-08-30 19:09:36	0|cfields|(i'll be PR'ing my threading refactor in a few hours which will let us kill off a ton of boost stuff, chrono included)
149 2016-08-30 19:10:01	0|cfields|jeremyrubin: boost depends everywhere? or in bench?
150 2016-08-30 19:10:08	0|jeremyrubin|in bench
151 2016-08-30 19:10:33	0|jeremyrubin|I also had a theory that std::thread was the reason my builds were failing. Apparently std::thread support is shakey in wine?
152 2016-08-30 19:10:35	0|cfields|ah, ok. that'll be nice to have :)
153 2016-08-30 19:10:56	0|jeremyrubin|or rather in the x-compiler
154 2016-08-30 19:11:01	0|jeremyrubin|seems to be fixed now though
155 2016-08-30 19:11:44	0|jeremyrubin|can't wait to see the -death- removal of boost::thread
156 2016-08-30 19:11:46	0|cfields|jeremyrubin: that'd be libstdc++. Surely it just uses win primitives under the hood, though
157 2016-08-30 19:12:18	0|jeremyrubin|cfields: see https://github.com/meganz/mingw-std-threads
158 2016-08-30 19:12:45	0|jeremyrubin|cfields: seems to be addressed though now; as when I compiled there was a version of std::thread present
159 2016-08-30 19:13:36	0|jeremyrubin|cfields: also, forgot to mention that test_bitcoin.exe runs ok; so that was part of my inkling it was a build setting
160 2016-08-30 19:13:54	0|cfields|jeremyrubin: i'm not sure what to say there, we rely on std::thread for mingw64 already
161 2016-08-30 19:14:12	0|cfields|sounds like you're chasing all kinds of things :)
162 2016-08-30 19:15:08	0|jeremyrubin|cfields: indeed
163 2016-08-30 19:23:25	0|jeremyrubin|cfields: master segfaults as well
164 2016-08-30 19:23:33	0|jeremyrubin|just finished my build
165 2016-08-30 19:23:37	0|cfields|jeremyrubin: interesting
166 2016-08-30 19:23:51	0|cfields|jeremyrubin: ok, still building here. Had to setup a VM, current OS is wonky
167 2016-08-30 19:26:59	0|jeremyrubin|cfields: I can run it with WINEDEBUG=+all but I don't really know how to read that
168 2016-08-30 20:49:57	0|GitHub24|[13bitcoin] 15jtimon opened pull request #8629: C++11: s/boost::scoped_ptr/std::unique_ptr/ (06master...060.13-boost-scoped-ptr) 02https://github.com/bitcoin/bitcoin/pull/8629
169 2016-08-30 21:16:01	0|cfields|jeremyrubin: finally got it built, crashes here too
170 2016-08-30 21:27:36	0|jeremyrubin|cfields: Cool/not cool
171 2016-08-30 21:28:00	0|cfields|jeremyrubin: is it only win32, not win64?
172 2016-08-30 21:28:24	0|jeremyrubin|cfields: didn't try win64; I'll do a build and report back shortly
173 2016-08-30 21:28:29	0|cfields|ok
174 2016-08-30 21:29:02	0|jeremyrubin|cfields: I guess it's not the most critical thing to fix, but I wanted to make travis print out benchmarking info in case tests are timing out due to poor performance will help debugging
175 2016-08-30 21:29:34	0|cfields|jeremyrubin: sure, sounds useful
176 2016-08-30 21:29:49	0|cfields|jeremyrubin: but since it's already busted in master, no need to make it a blocker for anything else you're working on
177 2016-08-30 21:29:55	0|jeremyrubin|cfields: Although looking at what's slow, it seems that PrevectorTestInt is really long on windows
178 2016-08-30 21:30:38	0|jeremyrubin|cfields: So I'm thinking about also changing the build_aux test driver to tee the log and print out the test messages so that it can see what it timed out on
179 2016-08-30 21:31:19	0|cfields|jeremyrubin: by all means. last time i poked at that, it fought me hard. printing that would be great.
180 2016-08-30 21:32:24	0|jeremyrubin|cfields: yeah I've spent the morning mucking through automake crap
181 2016-08-30 21:33:20	0|jeremyrubin|cfields: in any case; the current build system is functionally broken because if you add tests that make it go over 10 min it breaks :)
182 2016-08-30 21:34:10	0|cfields|heh, the test driver enforces that?
183 2016-08-30 21:36:01	0|jeremyrubin|cfields: travis does
184 2016-08-30 21:36:18	0|cfields|oh, sure
185 2016-08-30 21:36:22	0|jeremyrubin|cfields: it assumes tests failed if no output
186 2016-08-30 21:36:44	0|jeremyrubin|wait do you know where the build_aux/test_driver is generated?
187 2016-08-30 21:38:23	0|jeremyrubin|it looks like it comes from autogen
188 2016-08-30 21:38:27	0|cfields|comes from automake iirc
189 2016-08-30 21:40:04	0|jeremyrubin|ugh. yeah you're right
190 2016-08-30 21:49:34	0|jeremyrubin|cfields: `err:seh:setup_exception stack overflow 2656 bytes in thread 0024 eip 00002b619`
191 2016-08-30 21:53:58	0|jeremyrubin|cfields: Think I should just open an issue?