--- Day changed Wed Dec 04 2019
00:23 -!- Netsplit *.net <-> *.split quits: ysangkok, hardforkthis7
00:24 -!- Netsplit over, joins: hardforkthis7, ysangkok
00:45 -!- b10c [~Thunderbi@2001:16b8:3243:1100:bdee:a4b4:e4c:7487] has joined #bitcoin-core-pr-reviews     
01:10 -!- openoms [~quassel@cpc115066-stok20-2-0-cust313.1-4.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
01:11 -!- openoms [~quassel@cpc115066-stok20-2-0-cust313.1-4.cable.virginm.net] has quit [Client Quit]     
01:19 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
01:36 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
01:37 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
01:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 260 seconds]     
02:07 -!- orlovsky [~dr-orlovs@2a02:1205:500f:2e90:44e8:6142:feef:d44f] has joined #bitcoin-core-pr-reviews     
02:10 -!- dr-orlovsky [~dr-orlovs@2a02:1205:500f:2e90:d009:4f2d:a9d0:a572] has quit [Ping timeout: 276 seconds]     
02:51 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]     
02:56 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews     
03:03 -!- Mollie28Schmeler [~Mollie28S@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews     
03:08 -!- Mollie28Schmeler [~Mollie28S@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
03:12 -!- pinheadmz [~matthewzi@5.181.234.196] has joined #bitcoin-core-pr-reviews     
03:12 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
03:25 -!- pinheadmz [~matthewzi@5.181.234.196] has quit [Quit: pinheadmz]     
03:27 -!- pinheadmz [~matthewzi@5.181.234.196] has joined #bitcoin-core-pr-reviews     
03:52 -!- pinheadmz [~matthewzi@5.181.234.196] has quit [Quit: pinheadmz]     
03:53 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 276 seconds]     
03:58 -!- slivera__ [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]     
04:15 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews     
04:30 -!- potatoe_face [~potatoe_f@157.230.27.253] has quit [Ping timeout: 240 seconds]     
04:43 -!- potatoe_face [~potatoe_f@157.230.27.253] has joined #bitcoin-core-pr-reviews     
04:57 -!- pinheadmz [~matthewzi@45.152.180.252] has joined #bitcoin-core-pr-reviews     
05:12 -!- pinheadmz [~matthewzi@45.152.180.252] has quit [Quit: pinheadmz]     
05:17 -!- pinheadmz [~matthewzi@45.152.180.252] has joined #bitcoin-core-pr-reviews     
05:35 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
06:04 -!- Netsplit *.net <-> *.split quits: Nebraskka
06:09 -!- Netsplit over, joins: Nebraskka
06:13 -!- Netsplit *.net <-> *.split quits: Nebraskka
06:15 -!- pinheadmz [~matthewzi@45.152.180.252] has quit [Quit: pinheadmz]     
06:19 -!- Netsplit over, joins: Nebraskka
06:19 -!- pinheadmz [~matthewzi@45.152.180.252] has joined #bitcoin-core-pr-reviews     
06:38 -!- pinheadmz [~matthewzi@45.152.180.252] has quit [Ping timeout: 265 seconds]     
06:42 -!- pinheadmz [~matthewzi@45.152.180.252] has joined #bitcoin-core-pr-reviews     
07:13 < jnewbery> We'll get started in just under 3 hours
07:15 -!- jonatack [~jon@213.152.162.154] has joined #bitcoin-core-pr-reviews     
07:43 -!- pinheadmz [~matthewzi@45.152.180.252] has quit [Ping timeout: 250 seconds]     
07:46 -!- pinheadmz [~matthewzi@195.181.168.216] has joined #bitcoin-core-pr-reviews     
08:18 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
08:20 -!- pinheadmz [~matthewzi@195.181.168.216] has quit [Quit: pinheadmz]     
08:39 -!- sanoj_ [sid385278@gateway/web/irccloud.com/x-abxxlkwluecxrmfw] has quit []     
09:02 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
09:03 -!- pinheadmz [~matthewzi@195.181.168.216] has joined #bitcoin-core-pr-reviews     
09:18 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]     
09:19 -!- mattcruzz [~mattcruzz@109.246.19.100] has joined #bitcoin-core-pr-reviews     
09:38 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 250 seconds]     
09:45 -!- sanoj [sid385278@gateway/web/irccloud.com/x-hdosqynschnepghc] has joined #bitcoin-core-pr-reviews     
09:52 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews     
09:53 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
09:53 < ariard> starting in 7min
10:00 < ariard> #startmeeting
10:00 < emilengler> hello
10:00 < jnewbery> hi     
10:00 < _andrewtoth_> hi     
10:00 < fjahr> hi     
10:00 < sanoj> hi     
10:00 < jonatack> hi     
10:01 < ariard> today's PR is https://bitcoincore.reviews/16426.html : Reverse cs_main, cs_wallet lock order and reduce cs_main locking
10:01 < mattcruzz> hi     
10:01 < ariard> who had a chance to review the PR ?
10:01 < jonatack> yup     
10:01 < emilengler> negative
10:01 < ariard> jonatack: cool what was your review process?
10:02 -!- sebastianvstaa [~sebastian@85.203.15.17] has joined #bitcoin-core-pr-reviews     
10:02 < fjahr> started but not finished
10:02 < ariard> others did you read PR top message ? what the main problem this PR is trying to tackle ?
10:03 < jonatack> ariard: pulled the PR branch, opened diff locally with gitk, built with --enable-debug, ran tests, ran bitcoind, looked for warnings, read the commits one by on gitk, git grepped varois sites
10:03 < pinheadmz> hi!     
10:03 < _andrewtoth_> it's removing a requirement of locking cs_main before taking cs_wallet lock
10:04 < ariard> _andrewtoth: correct, does locking cs_main still occurs afterwards?
10:04 < _andrewtoth_> there's a lot of backstory to this PR, as several of your refactor PRs are linked
10:04 < ariard> jonatack: "git grepped varois sites"?
10:04 < jonatack> ariard: after jkczyz commented on the build warning, i then wanted to reproduce, so switched from gcc to clang, which showed the warning for me (reassuring)
10:04 < _andrewtoth_> cs_main still needs to be taken yes
10:04 < jonatack> ariard: note to self: build with clang more often
10:05 < ariard> jonatack: yeah having a Mac env is great to enable all clang options
10:05 < ariard> jonatack: that's a bit cumbersome when you're working with locks on core, we have different lock safety mechanisms following the platforms
10:05 < jonatack> ariard: then after you rebased, i verified the warning was gone by re-pulling your latest rebase and re-building with clang
10:05 -!- clicker-levitato [~clicker-l@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
10:06 < ariard> _andrewtoth_: right where is cs_main taken now ?
10:06 < ariard> jonatack: you run built with --enable-debug what the flag is doing ?
10:06 < jonatack> ariard: it seems to me that passing `--enable-debug` with clang on debian works too... it wanted to check that!
10:06 < jonatack> s/it/i/
10:07 < _andrewtoth_> ariard: inside the Chain interface, as opposed to wallet code, right?
10:07 < jonatack> ariard: git grepped various call sites to see that you covered them all
10:08 < ariard> _andrewtoth_: correct did you dig a bit on Chain interface ?
10:08 < ariard> and why it's a performance improvement to not hold the locks in the wallet code ?
10:08 < _andrewtoth_> hmm no that part is not clear to me yet
10:08 < _andrewtoth_> if lock is taken inside chain anyways, why is it a benefit?
10:08 < jkczyz> hi     
10:08 < ariard> jonatack: --enable-debug is a different check than clang, it's going to enable DEBUG_LOCKORDER
10:08 < jonatack> ariard: running with --enable-debug adds the -DDEBUG -DDEBUG_LOCKORDER flags afaik
10:09 < ariard> jonatack: exactly
10:09 < Talkless> hi     
10:09 < Talkless> jonatack: do you ever use --enable-werror ?
10:09 < Talkless> or you just save build output & grep warnings..?
10:09 < jonatack> Talkless: no, i need to try that. the latter one, correct :)
10:10 < Talkless> ok     
10:10 < ariard> jonatack: did you dig into src/sync.cpp to undersand effet of DEBUG_LOCKORDER?
10:10 < jonatack> i'd like to try the various options practicalswift lists here: https://github.com/bitcoin/bitcoin/issues/17344
10:11 < ariard> _andrewtoth_: it's a benefit because right now we hold the cs_main at beginning of every RPC call
10:11 < jonatack> since i reviewed the PR with the uninitialized bug that caused the patch release 0.19.0.1 and would like to catch those in the future
10:11 < ariard> _andrewtoth_ : and it's hold until the RPC finished
10:12 < ariard> with this patchset: cs_main is just hold to fetch chain data and no more
10:12 < _andrewtoth_> i see thanks
10:12 < ariard> we lock cs_main just-in-time if you prefer
10:13 < ariard> jonatack: oh that's an interesting list thanks
10:13 -!- b10c [~Thunderbi@2001:16b8:3243:1100:bdee:a4b4:e4c:7487] has quit [Ping timeout: 250 seconds]     
10:14 < ariard> jonatack: yes I think generally we have a good deal of improvements of using sanitizers/automated tests/fuzzing
10:14 < jonatack> ariard: sync.cpp::L31-215 took a cursory look at the effects of DEBUG_LOCKORDER, will spend more time in that file
10:14 < jonatack> ariard: yes!
10:14 < ariard> While where reading the code which commit(s) attracted your attention ?
10:15 < _andrewtoth_> there are comments mentioning this could potentially improve IBD. How would it? Wouldn't it only affect performance if wallet rpcs are called during IBD?
10:15 < ariard> What should be carefully examined ? What could go wrong ?
10:16 < ariard> _andrewtoth_ : have a look on validationinterface, right now wallet lock cs_main in BlockConnected/BlockDisconnected
10:16 < jonatack> ariard: the last commit that removes the locks seems potentially the most dangerous
10:16 < ariard> I mean wallet is an indirect consumer of validationinterface through the Chain interface
10:17 < ariard> jonatack: yes DEBUG_LOCKORDER enable a process struct to pair lock order and check at any new tacking if it doesn't invert
10:18 < ariard> and process struct have pointers back to a per-thread struct which trace lock position in file
10:18 < ariard> jonatack: yes last commit is the most painful one to review, forgetting a lock somewhere could cause deadlock
10:19 -!- pinheadmz [~matthewzi@195.181.168.216] has quit [Quit: pinheadmz]     
10:21 < jonatack> ariard: did you experience any deadlocks while working on this PR?
10:21 < ariard> okay next question : Did this PR changes the wallet behavior?
10:21 < jonatack> (if yes, how did they show themselves?)
10:22 < ariard> jonatack: ahah ofc but it was in the wallet test framework because we don't take locks through the Chain interface there
10:22 < ariard> but the wild way of LOCK(cs_main)
10:23 < ariard> jonatack: they showed up thanks to --enable-debug
10:23 < _andrewtoth_> ariard: I think it only changes it if cs_main is locked by something else, then it has to wait. Otherwise, no it does not
10:23 < _andrewtoth_> *doesn't have to wait
10:24 < _andrewtoth_> up until it needs to get something from the chain
10:25 < jonatack> ariard: What gave you the initial idea to begin working on this series of PRs? Something you read, that someone said, or the idea came to you on its own?
10:25 < ariard> _andrewtoth_: yes that should change thread concurrency which should be better, I was more thinking about wallet behavior if the sense of different return values or breaking some internal features
10:26 < _andrewtoth_> then the answer is no
10:27 < jonatack> Given that so few tests needed to be changed, I surmised no wallet behavior change other than perhaps performance. Did you bench it?
10:27 < ariard> jonatack: I wish a more modular core project with clean, well-functional interfaces, and this serie of PR was a good beginning
10:28 < jonatack> ariard: "a good beginning"... hehe, yes, i'd say so! +1
10:28 < ariard> _andrewtoth_: well actually it may have change if wallet do something like A=getheight(), B=getheight(), if A == B do something, if A != B do something else
10:29 < _andrewtoth_> ahh yes
10:29 < ariard> _andrewtoth_: I've verified all the callsites which are making assumptions on a particular tip and don't find anything wrong
10:29 < ariard> most of them are related to the rescan code, which currently don't lock the cs_main and verify every previous value returned from the Chain interface
10:30 < jonatack> ariard: did you use gdb to verify, or?
10:30 < ariard> you should grep all the "getBlockHeight" "getBlockTime"
10:30 < jonatack> or just grepping
10:31 < ariard> and try to think about what have changed in the sense of wallet view of the blockchain has changed or not
10:31 < ariard> jonatack: yeah just grep "get*" in wallet code
10:31 < ariard> jonatack: I don't see whagt gdb would discover there
10:32 < ariard> next question : Why does the lock order need to be inverted all at once?
10:32 < ariard> (easy one)
10:33 < jkczyz> otherwise there could be a deadlock
10:33 < jonatack> ariard: to check values, as you mentioned verifying values returned. It's interesting to see how others debug bitcoin core. For example, i've learned a lot from watching achow101's live coding sessions on twitch tv
10:34 < ariard> jkczyz: correct
10:34 < jonatack> as soon as he gets stuck, he often jumps right into gdb.
10:34 < ariard> jonatack: what were your biggest learnings ?
10:35 < ariard> jonatack: honestly for debugging it's more adding more printers and take pen and papers and think what I got wrong
10:35 < ariard> like drawing control flow, see where there is write/read on the modified data structures
10:36 < ariard> depend what kind of bugs you're tracking but IMO gdb is overkill for a project like bitcoin core
10:36 < jonatack> ariard: from watching achow101 (so far): compiler-driven debugging, gdb use, inspecting wallet files using Berkeley DB special commands (located in db4/bin), using flame graphs.
10:36 < ariard> jonatack: yes we should all keep an eye on flame graph when we modify part of the code which touch performance
10:37 < jonatack> ariard: yes, i tend to begin with prints and asserts but have not found myself deep in the weeds yet in my PRs since they have been simple ones
10:37 < jonatack> so more for reviewing others' PRs
10:37 < ariard> but I think how you're debugging is also super related to what part of codebase you're working on, P2P != wallet
10:38 < ariard> jonatack: when reviewing others' PRs I like to go through modified changes and tweak them to see if there is a better way of doing it
10:38 < _andrewtoth_> jonatack: what is compiler-driven debugging?
10:38 < ariard> that force you to understand the code
10:38 < jonatack> ariard: yes, i noticed that you have always been assidious and good wrt drawing control flow
10:39 < jonatack> assiduous*
10:39 < jonatack> tweaking others' code is a great way to go +1
10:40 < jonatack> compiler-driven debugging: relying on compiler errors to see what's not working and fix it
10:40 < ariard> next question: Do you expect this PR to have any impact on performace? But we already talk a bit about this, so let's readjust the question how could we make wallet code better to service concurrently multiple RPC calls ?
10:41 < jkczyz> moving the code to a more modular state will also ease unit testing
10:42 < jkczyz> ariard: perhaps using a per-wallet lock would help
10:42 < ariard> jkczyz: ofc I think we were considering with Marco to disable block writing just to fuzz p2p/validation stack without burning your disks
10:42 < jonatack> yes. could enable shifting more testing from functional to unit (faster), or better coverage
10:43 < ariard> jkczyz: it's already the case
10:43 < jkczyz> ah, didn't realize that
10:44 < jonatack> and modularity could help improve fuzzing and PBT testing as well
10:44 < ariard> jkczyz: I think the way of thinking what are the main data structures of the wallet, like coins, keys, address, what can be accessed concurrently and for what we need a synchronized view
10:44 < ariard> like you don't want both RPC building a transaction spending the same coin
10:45 < ariard> and you don't want to return same address twice
10:45 < ariard> but all read rpc like displaying coins received could be concurrent
10:45 < ariard> jonatack: PBT testing ?
10:46 < jonatack> ariard: property-based testing
10:46 < ariard> a bit off-topic but having more fine-grained lock in wallet is an interesting topic to dig in
10:46 < ariard> if people are looking for cool PRs to work on (I don't plan to do this)
10:47 < ariard> next question: Can you think of any other way to remove the cs_main lock from the wallet code?
10:47 < jkczyz> I see what you are saying. I was thinking of different wallets. For the same wallet, should concurrent RPCs that "write" be disallowed then? Or at least while holding a higer-level lock?
10:47 < jonatack> (chris stewart has a large PR to add a bunch of PBT that needs review and we ought to add PBT coverage for instance to the BIP157-158 changes, there may be low-hanging fruit there)
10:48 < jkczyz> (or rather should require holding a higher-level lock)
10:49 < ariard> jkczyz: "should concurrent RPcs that "write" be disallowed then" I think you should have a cs_coins lock to hold to avoid concurrent write
10:49 < ariard> so yes should require holding a higher-level lock but not necessary the actual cs_wallet one
10:49 < ariard> jonatack: what the PR already, would try to review it
10:49 -!- clicker-levitato [~clicker-l@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: clicker-levitato]     
10:51 < jonatack> ariard: https://github.com/bitcoin/bitcoin/pull/14430
10:51 < jonatack> "Add more property based tests for basic bitcoin data structures"
10:51 < jonatack> it's on my review list too
10:52 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Remote host closed the connection]     
10:52 < jonatack> ariard: "having more fine-grained lock in wallet"... interesting
10:52 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-pr-reviews     
10:53 < ariard> jonatack: yes you need #16426, because without that would be useless
10:53 < jonatack> ariard: Do you envision other building other changes on this PR in addition to those you describe in your PR body?
10:53 < ariard> next question: What further changes could be build on top of this PR?
10:54 < jonatack> snap! :D
10:55 < ariard> jonatack: okay I have some changes building on top of it on the rescan logic
10:55 < ariard> well it's not exactly on top of it but it's going to be easier to review without having to care about cs_main
10:56 < ariard> and more generally drying-up the Chain interface until it makes sense to have other types of client using it
10:56 < ariard> like lightning daemons ;)
10:57 < jonatack> afaict #16426 should get in soon if no bugs are found during review, better to merge it not too late in this release cycle to have time to catch anything unexpected
10:57 < ariard> jonatack: it's really biased but yes that's a blocker to more broader improvements both on the wallet-side on interface-sides
10:57 < ariard> and many of them can be worked in parallel after it
10:59 < ariard> and the Chain interface itself maybe should be splitted in different ones, like at least one for fee estimation
10:59 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 268 seconds]     
11:00 < ariard> #endmeeting
11:00 < jonatack> ariard: interesting
11:01 < _andrewtoth_> ariard: thanks!
11:01 < ariard> okay thanks all for participation, will hang here a bit more if you have questions, and once #16426 merged I will open issues to keep track what can be do as follow-ups
11:01 < jonatack> ariard: about lightning, fwiw i'll ping you soon to talk about the anchor outputs RFC PR 688
11:01 < jonatack> thanks ariard and everyone!
11:02 < mattcruzz> ariard: Thanks for hosting, there's some interesting topics I need dig into now
11:02 -!- mattcruzz [~mattcruzz@109.246.19.100] has left #bitcoin-core-pr-reviews []     
11:02 < ariard> yes to everyone don't censor yourself for reviewing, everyone is doing mistake and you're not going to break anything by doing a review
11:02 < ariard> quite the contrary :)
11:04 < jonatack> ariard: perhaps add a roadmap about your ideas in https://github.com/bitcoin/bitcoin/projects/ (or as part of https://github.com/bitcoin/bitcoin/projects/10)
11:04 < jonatack> "Process separation"
11:04 -!- pinheadmz [~matthewzi@195.181.168.216] has joined #bitcoin-core-pr-reviews     
11:05 < jonatack> and very good point about not censoring yourself and reviewing!
11:06 < fanquake> ariard if you want open a follow ups issue in advance of that being merged, feel free. Better to capture all the issues etc now, rather than digging through comments post-merge.
11:06 < ariard> fanquake: one issue per-idea or big issues and listing everything ?
11:08 < fanquake> 1 issue per big idea/refactor is probably fine. If there's nits/small follows up, probably best to combine them all into a single issue.
11:09 < fanquake> Main point is just not to lose PR commentary/things that should be done as follow ups post merge.
11:17 -!- pinheadmz [~matthewzi@195.181.168.216] has quit [Quit: pinheadmz]     
11:27 < jonatack> ariard: (don't forget to PR adding the meeting log to https://github.com/bitcoin-core-review-club/bitcoin-core-review-club.github.io)
11:57 -!- jonatack [~jon@213.152.162.154] has quit [Ping timeout: 268 seconds]     
12:13 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-core-pr-reviews     
12:17 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
12:22 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving]     
12:54 -!- pinheadmz [~matthewzi@195.181.168.216] has joined #bitcoin-core-pr-reviews     
13:32 -!- vindard [~vindard@200.7.90.146] has joined #bitcoin-core-pr-reviews     
13:34 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
13:37 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
13:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 260 seconds]     
14:06 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
14:12 -!- davterra [~dulyNoded@195.242.213.120] has joined #bitcoin-core-pr-reviews     
14:15 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
14:39 -!- pinheadmz [~matthewzi@195.181.168.216] has quit [Read error: Connection reset by peer]     
14:40 -!- pinheadmz [~matthewzi@208.69.41.72] has joined #bitcoin-core-pr-reviews     
14:46 -!- shesek [~shesek@5.22.135.198] has joined #bitcoin-core-pr-reviews     
14:46 -!- shesek [~shesek@5.22.135.198] has quit [Changing host]     
14:46 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
14:50 -!- davterra [~dulyNoded@195.242.213.120] has quit [Ping timeout: 250 seconds]     
14:51 -!- davterra [~dulyNoded@195.242.213.120] has joined #bitcoin-core-pr-reviews     
14:59 < jonatack> Talkless: agreed, --enable-werror is useful: wallet/wallet.cpp:2528:61: error: reading variable 'm_last_block_processed_height' requires holding mutex 'cs_wallet' [-Werror,-Wthread-safety-analysis]
15:00 < jonatack> and halts immediately. Will use!
15:19 -!- tinova [~tinova@lemoncat.org] has quit [Ping timeout: 276 seconds]     
15:20 -!- tinova [~tinova@lemoncat.org] has joined #bitcoin-core-pr-reviews     
16:10 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Quit: Leaving]     
16:40 -!- vindard [~vindard@200.7.90.146] has quit [Read error: Connection reset by peer]     
16:41 -!- pinheadmz [~matthewzi@208.69.41.72] has quit [Quit: pinheadmz]     
16:43 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews     
18:03 -!- davterra [~dulyNoded@195.242.213.120] has quit [Quit: Leaving]     
18:05 -!- davterra [~dulyNoded@c-73-221-225-225.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
19:18 < jnewbery> Meeting log is up: https://bitcoincore.reviews/16426.html
19:58 -!- felixfoertsch [~felixfoer@92.117.48.176] has joined #bitcoin-core-pr-reviews     
20:00 -!- felixfoertsch23 [~felixfoer@92.117.34.67] has quit [Ping timeout: 265 seconds]     
20:49 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 250 seconds]     
20:50 -!- pinheadmz [~matthewzi@135-180-42-232.fiber.dynamic.sonic.net] has joined #bitcoin-core-pr-reviews     
20:54 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-pr-reviews     
21:37 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 260 seconds]     
21:37 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 260 seconds]     
21:37 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
21:38 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer]     
21:41 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews     
22:02 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
22:03 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-pr-reviews     
22:49 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-core-pr-reviews