36 entries in 0.582s
a111: Logged on 2017-08-06 03:43 asciilifeform: my suspicion is that the
bdb locks patch somehow has no effect when
bdb built on netbsd
mircea_popescu: TomServo yeah it's required if you want to sync,
bdb as shipped with original btc croaks on larger b
locks thestringpuller: mod6: was this started from a /clean/ env or is this trying to load up a blockchain from christmas past? << I completely nuked the datadir .bitcoin with rm -rf *; whenever I do an rpc call after the thing _tries_ to spin up, it borks. crashes without anything except what was in the db.log. I'm almost certain it's an issue with
bdb because no b
locks are downloaded or anything. cause it connects to the node I specify gets basic
BingoBoingo: ben_vulpes: LibreSSL node also runs with ~1GB of ram utilized at startup after last
BDB locks patch because OpenBSD malloc something or other
ascii_field: as in, didn't have the
bdb locks fix patch applied ?
assbot: Logged on 20-09-2015 09:36:21; BingoBoingo: On OpenBSD (non-pogoable) the latest
BDB locks fix added ~800MB of memory allocation for bitcoind
BingoBoingo: On OpenBSD (non-pogoable) the latest
BDB locks fix added ~800MB of memory allocation for bitcoind
☟︎ mircea_popescu: asciilifeform i can actually unwedge it. i am satisfied the problem here is a subtle memory issue (not directly related to the
bdb locks thing). specifically, to verify block 367851 bitcoind needs a certain amount of CONTIGUOUS memory. but it doesn't know this.
BingoBoingo: joecool: With the anticipated spam attacks ideally you will want to bolt the Ophanage amputation and thermonuke modifications to whatever you choose. Also make sure you fix the
BDB locks problem in your chose codebase. Anything post 0.3.21 and pre 0.8 should be fine. If you don't have particular things you fuss over 0.5.4'stator/rotor' is probably as close to idea as you will come
BingoBoingo: <asciilifeform> ph0rk ?! <<
BDB exhaustion, upping max
locks and DBobjects fixes
punkman: you gotta read
BDB code for those
locks ascii_field: and was forgotten when
bdb locks patch discovered
mircea_popescu: in general, going by the "never one single bug in kitchen, and noting that
bdb locks are a resource of the kind that pointers are, just one easier to exhaust, i propose this as likely, on the basis of my business heuristics.
mod6: BingoBoingo: cool. ive got openssl/
bdb/boost built now on obsd 5.6, then just gotta apply sublte obsd changes to v0.5.3.1 and then try the static build. if all works & pulls b
locks, I'll make patches: one for the v0.5.3.1 source and one for `auto.sh' (which needs a few tweaks). maybe you can just point at that instead. anyway, no worries.
mod6: at first, I just set max
locks to 40000, and nothing else, but ended up with liek 265Gb of
BDB Tx logs
mod6: I was able to get upto the current block 2 different times with patches 1->5 (which includes ascii's patches, ben's patch, and my removal of checkpoints) with two seperate
bdb configs. The first one just changed this: dbenv.set_lk_max_
locks(40000); But ended up with a huge amount of
BDB tx log files.
mircea_popescu: this is useful if you keep stopping every x b
locks, backuping
bdb files
mircea_popescu: asciilifeform
bdb needs a set_lk_max_
locks directive to function properly with larger b
locks.
mircea_popescu: asciilifeform: does anyone know the cause of permanent blockchain wedging in 0.5.3 ? << i am pretty certain it's the
bdb locks initialisation issue.
jborkl_: people were all up in arms about having 80 to 1000 unconfirmed transactions waiting. with NO testing, people made larger b
locks - that broke
BDB