< luke-jr> 9mo old said her first non-mama/papa word: "dot" [dot dot]
< GitHub7> [bitcoin] isle2983 opened pull request #8625: [doc] - clarify statement about parallel jobs in rpc-tests.py (master...rpcTestsDoc) https://github.com/bitcoin/bitcoin/pull/8625
< jeremyrubin> luke-jr: ls
< jeremyrubin> oops
< * jeremyrubin> shameful
< isle2983> usually they start with 'grep' before getting into directory navigation...
< luke-jr> jeremyrubin: ls: cannot open directory .: Transport endpoint is not connected
< 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 ;)
< luke-jr> :P
< jeremyrubin> ANyways; what I was going to ask generally is about how std::thread is used currently in core
< jeremyrubin> I can't seem to get it to properly link or something in wine
< jeremyrubin> (in use on my own code)
< jeremyrubin> but on master it is already in use in httpserver.h
< GitHub173> [bitcoin] netsafe opened pull request #8626: Berkeley DB v6 compatibility fix (master...netsafe-patch-1) https://github.com/bitcoin/bitcoin/pull/8626
< GitHub184> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/89de1538ce1f...c01a6c48b982
< GitHub184> bitcoin/master 1467561 isle2983: [doc] - clarify statement about parallel jobs in rpc-tests.py
< GitHub184> bitcoin/master c01a6c4 MarcoFalke: Merge #8625: [doc] - clarify statement about parallel jobs in rpc-tests.py...
< GitHub194> [bitcoin] MarcoFalke closed pull request #8625: [doc] - clarify statement about parallel jobs in rpc-tests.py (master...rpcTestsDoc) https://github.com/bitcoin/bitcoin/pull/8625
< GitHub114> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c01a6c48b982...7b9889586501
< GitHub114> bitcoin/master eda4cfb Andrew Chow: Create an easy to use gitian building script...
< GitHub114> bitcoin/master 498d8da Andrew Chow: Check for OSX SDK
< GitHub114> bitcoin/master 6ffd6b4 Andrew Chow: Create option to detach sign gitian builds and not commit the files in the script...
< GitHub123> [bitcoin] laanwj closed pull request #8566: Easy to use gitian building script (master...gitian-build-script) https://github.com/bitcoin/bitcoin/pull/8566
< GitHub4> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7b9889586501...2b23dbaee5b8
< GitHub4> bitcoin/master 203f212 Pieter Wuille: Reduce default number of blocks to check at startup
< GitHub4> bitcoin/master 2b23dba Wladimir J. van der Laan: Merge #8611: Reduce default number of blocks to check at startup...
< GitHub82> [bitcoin] laanwj closed pull request #8611: Reduce default number of blocks to check at startup (master...fastcheck) https://github.com/bitcoin/bitcoin/pull/8611
< jonasschnelli> What does "2016-08-29 20:22:53 socket send error Bad file descriptor (9)" mean? Running out of file descriptors?
< jonasschnelli> One of my local node ran into this over night
< wumpus> I don't think it's that, '9' isn't really a high number
< wumpus> could be a use-after-close of some kind
< jonasschnelli> It resulted in a shutdown at least
< jonasschnelli> Also has bad allocs on the same machine.. could be memory related, though, its a brand new computer (means nothing, i know)
< wumpus> ugh :/
< jonasschnelli> DDR3L ram
< wumpus> yes, memory corruption could definitely result in this, maybe the fd field was overwritten
< wumpus> what do you exactly mean by 'bad allocs'?
< jonasschnelli> bitcoind crashed with a std::expection bad alloc (I don't have the exact output right now)
< jonasschnelli> Here we go:
< jonasschnelli> EXCEPTION: St9bad_alloc
< wumpus> that's running out of memory, not memory corruption
< jonasschnelli> std::bad_alloc
< jonasschnelli> bitcoin in ProcessMessages()
< jonasschnelli> hmm....
< 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)
< jonasschnelli> free -h --> total 16GB
< wumpus> strange. Does it have swap enabled?
< jonasschnelli> Headless debian with only bitcoind running..
< wumpus> swap is extrememly important in Linux, even if you have enough memory, otherwise (AFAIK) it won't overcommit virtual memory and such
< jonasschnelli> "free" tells me, mem: Total, 15GB, used 2.7GB (restarted node with -dbcache=4000), Swap: total 17GB, used 0GB
< wumpus> okay, that's not it then
< wumpus> really strange
< jonasschnelli> The machine has 16GB physical memory... I don't think it ran out of memory
< jonasschnelli> I keep en eye on that
< wumpus> did you change dbcache?
< jonasschnelli> Yes. Always ran with -dbache=4000
< jonasschnelli> But codewise its pure master
< jonasschnelli> at a5bb6387f751e630c329f34cac2d38bffa8ff9cf
< wumpus> ok... no, that won't be the issue I think
< jonasschnelli> Heres the debug log: http://paste.ubuntu.com/23111528/
< jonasschnelli> Line 839 is the std::bad_alloc
< jonasschnelli> then there are some socket send error Bad file descriptor (9)
< jonasschnelli> Really strange the "Misbehaving: (0 -> 100) BAN THRESHOLD EXCEEDED" ... I hope its not an exploit.
< wumpus> well I think the bad_alloc causes that rejection/banning
< wumpus> it's unfortunate that we don't know which exact allocation failed
< wumpus> apparently it's somewhere in the ConnectBlock() inputs logic
< wumpus> 0000000000000000243ecc39a5c110fea174e34e4a2d00b5f2038ab2e2f5cf70 is the valid block at height 322006 - so if it was an exploit, it's not by sending a corrupted block
< wumpus> kind of bad that a bad_alloc causes block rejection though
< wumpus> after restarting you probably had to explicitly re-verify the block?
< jonasschnelli> wumpus: I had to reindex at some point... IIRC, I had to do it afterwards.
< jonasschnelli> But maybe the reindex was on a different datadir/run
< jonasschnelli> At L912 is looks after a valid restart without reindex
< wumpus> I doubt it can be the result of any of today's commits
< sipa> wumpus: i think 9 may be the errno code?
< wumpus> sipa: ah, yes, probably
< jonasschnelli> The node above stalled at height 322005
< jonasschnelli> last 3000 lines of debug log: http://paste.ubuntu.com/23112229/
< jonasschnelli> getblockchaininfo: http://paste.ubuntu.com/23112227/
< jonasschnelli> No new logprinf since 2h
< jonasschnelli> But bitcoind is running: jonassc+ 1000 89.6 8.0 1614436 1331624 pts/1 SLl+ 13:40 204:02 ./src/bitcoind --dbcache=4000
< jonasschnelli> deadlock?
< sipa> jonasschnelli: getchaintips
< sipa> jonasschnelli: getpeerinfo
< jonasschnelli> sipa: http://paste.ubuntu.com/23112236/
< jonasschnelli> peerinfo: http://paste.ubuntu.com/23112238
< jonasschnelli> attached gdb and bt is: http://paste.ubuntu.com/23112247/
< jonasschnelli> wait.. thats useless. nm
< jonasschnelli> RPC server works.. but network layer seems to be dead
< sipa> jonasschnelli: thread apply all bt
< jonasschnelli> sipa: was just doing this:
< jtimon> now that we're C++11, what should I use instead of boost::scoped_ptr<> ?
< sipa> std::unique_ptr
< sipa> jonasschnelli: what is on net.cpp:1909
< * jonasschnelli> looking
< jonasschnelli> messageHandlerCondition.timed_wait(lock, boost::posix_time::microsec_clock::universal_time() + boost::posix_time::milliseconds(100));
< sipa> i don't see any deadlock
< sipa> or any lock at all, even
< jonasschnelli> Is there a reason why a peer request headers and compact blocks (sendheaders and sendcmpct) to nodes not signaling NODE_NETWORK?
< jonasschnelli> I guess an SPV node at 70014 can just ignore those..
< jtimon> sipa thanks!
< sipa> jonasschnelli: read the bip
< sipa> it explicitly explains that :)
< jonasschnelli> sipa: Thanks. I should do that.
< jeremyrubin> Can anyone run `make bench` on wine 32 bit build?
< cfields> jeremyrubin: i can in a little bit
< jeremyrubin> kk thanks
< cfields> jeremyrubin: actually, "teach a man to fish" and all that... :)
< cfields> jeremyrubin: have you tried building/running for win32?
< jeremyrubin> cfields: yes
< cfields> jeremyrubin: you had issues, or just want to compare results?
< jeremyrubin> cfields: wine: Unhandled page fault on read access to 0x00000004 at address 0x6117a9 (thread 0009), starting debugger...
< jeremyrubin> cfields: errors. Playing around with things it seems to be some kind of link time issue I suspect
< cfields> jeremyrubin: errors running? or running under gdb? 'cause wine+gdb is a different beast :)
< 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.
< jeremyrubin> cfields: not under gdb
< 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
< jeremyrubin> cfields: I tried adding "-static" to LDFLAGS
< cfields> jeremyrubin: win32 builds are already static
< * jonasschnelli> setups mingw32 depends builds
< cfields> jeremyrubin: i'm afraid i'm missing some context, though. Does the current bench code not work in win32?
< jeremyrubin> cfields: I don't think so; let me test on master
< jeremyrubin> cfields: where can I see the static flags? I don't think they're set for bench
< cfields> jeremyrubin: ah, ok
< cfields> jeremyrubin: they're kinda a maze, sec
< jeremyrubin> cfields: `bench_bench_bitcoin_LDFLAGS = $(RELDFLAGS) $(AM_LDFLAGS) $(LIBTOOL_APP_LDFLAGS)`
< jeremyrubin> in Makefile.bench.include
< cfields> jeremyrubin: IIRC it's the LIBTOOL_APP_LDFLAGS that sets static
< jeremyrubin> in Makefile.test.include `test_test_bitcoin_LDFLAGS = $(RELDFLAGS) $(AM_LDFLAGS) $(LIBTOOL_APP_LDFLAGS) -static`
< cfields> # -static is interpreted by libtool, where it has a different meaning.
< cfields> # In libtool-speak, it's -all-static.
< cfields> AX_CHECK_LINK_FLAG([[-static]],[LIBTOOL_APP_LDFLAGS="$LIBTOOL_APP_LDFLAGS -all-static"])
< 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)
< cfields> ok. trying here too.
< cfields> you're building with depends?
< cfields> or is that why you hacked it to be dependency-less?
< jeremyrubin> I'm building by this:
< jeremyrubin> (well, whatever it says in doc/build-windows)
< cfields> ok
< jeremyrubin> cd depends; make HOST=i686-w64-mingw32 -j4; cd ..; ./configure --prefix=`pwd`/depends/i686-w64-mingw32; make
< cfields> right
< jeremyrubin> also you may want this:
< jeremyrubin> std::chrono::duration<double> result {std::chrono::system_clock::now().time_since_epoch()};
< jeremyrubin> return result.count();
< jeremyrubin> for bench.cpp gettimedouble
< jeremyrubin> (not sure if the sys/time.h include is problematic)
< cfields> yea, we should aim to nuke those.
< jeremyrubin> Yeah I can separately PR nuking them; pretty easy to remove that & the boost depends as well
< 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)
< cfields> jeremyrubin: boost depends everywhere? or in bench?
< jeremyrubin> in bench
< jeremyrubin> I also had a theory that std::thread was the reason my builds were failing. Apparently std::thread support is shakey in wine?
< cfields> ah, ok. that'll be nice to have :)
< jeremyrubin> or rather in the x-compiler
< jeremyrubin> seems to be fixed now though
< jeremyrubin> can't wait to see the -death- removal of boost::thread
< cfields> jeremyrubin: that'd be libstdc++. Surely it just uses win primitives under the hood, though
< jeremyrubin> cfields: seems to be addressed though now; as when I compiled there was a version of std::thread present
< jeremyrubin> cfields: also, forgot to mention that test_bitcoin.exe runs ok; so that was part of my inkling it was a build setting
< cfields> jeremyrubin: i'm not sure what to say there, we rely on std::thread for mingw64 already
< cfields> sounds like you're chasing all kinds of things :)
< jeremyrubin> cfields: indeed
< jeremyrubin> cfields: master segfaults as well
< jeremyrubin> just finished my build
< cfields> jeremyrubin: interesting
< cfields> jeremyrubin: ok, still building here. Had to setup a VM, current OS is wonky
< jeremyrubin> cfields: I can run it with WINEDEBUG=+all but I don't really know how to read that
< GitHub24> [bitcoin] jtimon opened pull request #8629: C++11: s/boost::scoped_ptr/std::unique_ptr/ (master...0.13-boost-scoped-ptr) https://github.com/bitcoin/bitcoin/pull/8629
< cfields> jeremyrubin: finally got it built, crashes here too
< jeremyrubin> cfields: Cool/not cool
< cfields> jeremyrubin: is it only win32, not win64?
< jeremyrubin> cfields: didn't try win64; I'll do a build and report back shortly
< cfields> ok
< 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
< cfields> jeremyrubin: sure, sounds useful
< cfields> jeremyrubin: but since it's already busted in master, no need to make it a blocker for anything else you're working on
< jeremyrubin> cfields: Although looking at what's slow, it seems that PrevectorTestInt is really long on windows
< 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
< cfields> jeremyrubin: by all means. last time i poked at that, it fought me hard. printing that would be great.
< jeremyrubin> cfields: yeah I've spent the morning mucking through automake crap
< 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 :)
< cfields> heh, the test driver enforces that?
< jeremyrubin> cfields: travis does
< cfields> oh, sure
< jeremyrubin> cfields: it assumes tests failed if no output
< jeremyrubin> wait do you know where the build_aux/test_driver is generated?
< jeremyrubin> it looks like it comes from autogen
< cfields> comes from automake iirc
< jeremyrubin> ugh. yeah you're right
< * jeremyrubin> ponders just making the tests periodically put a '.' to stderr to solve it
< jeremyrubin> cfields: `err:seh:setup_exception stack overflow 2656 bytes in thread 0024 eip 00002b619`
< jeremyrubin> cfields: Think I should just open an issue?