< 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
< 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>
then there are some socket send error Bad file descriptor (9)
< jonasschnelli>
Really strange the "Misbehaving: 85.214.213.91:8333 (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
< 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
< 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
< 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