12019-05-06T00:00:02  *** Ultifest2 has quit IRC
  22019-05-06T00:00:55  *** scoop has quit IRC
  32019-05-06T00:05:17  *** scoop has joined #bitcoin-core-dev
  42019-05-06T00:05:29  *** cpow has joined #bitcoin-core-dev
  52019-05-06T00:10:01  *** luke-jr has joined #bitcoin-core-dev
  62019-05-06T00:10:20  *** scoop has quit IRC
  72019-05-06T00:10:28  *** scoop has joined #bitcoin-core-dev
  82019-05-06T00:17:57  *** Skirmant has quit IRC
  92019-05-06T00:24:44  *** lukedashjr has joined #bitcoin-core-dev
 102019-05-06T00:24:57  *** luke-jr has quit IRC
 112019-05-06T00:29:11  *** lukedashjr is now known as luke-jr
 122019-05-06T00:41:40  *** drexl has joined #bitcoin-core-dev
 132019-05-06T00:42:06  *** ccdle12 has quit IRC
 142019-05-06T00:42:15  *** ccdle12 has joined #bitcoin-core-dev
 152019-05-06T00:48:05  *** Bullit has quit IRC
 162019-05-06T00:53:46  *** Evel-Knievel has quit IRC
 172019-05-06T00:54:04  *** Evel-Knievel has joined #bitcoin-core-dev
 182019-05-06T01:16:36  <tryphe> i noticed read() accepts 'size_t for its third argument but 'int'
 192019-05-06T01:16:55  <tryphe> whoops, 'int' is used here: https://github.com/bitcoin/bitcoin/blob/master/src/random.cpp#L290
 202019-05-06T01:17:24  <tryphe> particularly 'have' and 'NUM_OS_RANDOM_BYTES' are int
 212019-05-06T01:17:40  <tryphe> is this intended for some reason, or a bug?
 222019-05-06T01:21:13  <sipa> it's a constant, it doesn't matter
 232019-05-06T01:23:06  <tryphe> but why?
 242019-05-06T01:23:19  <tryphe> size_t is unsigned, int is signed
 252019-05-06T01:24:35  <sipa> 32 is 32
 262019-05-06T01:25:16  *** Karyon has quit IRC
 272019-05-06T01:25:31  <tryphe> right but it doesn't really answer my question
 282019-05-06T01:25:40  *** Karyon has joined #bitcoin-core-dev
 292019-05-06T01:26:14  <gmaxwell> tryphe: use of an unsigned value would potentially risk random unsigned promotions elsewhere.
 302019-05-06T01:26:26  <gmaxwell> Which is a common source of gnarly bugs.
 312019-05-06T01:26:58  <gmaxwell> 32 fortunately fits in every type (except bool. :P )
 322019-05-06T01:29:11  <tryphe> gmaxwell, makes sense, it's that i would think doing that kind of thing might cause platform issues down the road, maybe similar to the way "word" became ambiguous
 332019-05-06T01:30:25  *** promag_ has quit IRC
 342019-05-06T01:35:40  *** scoop has quit IRC
 352019-05-06T01:36:06  *** scoop has joined #bitcoin-core-dev
 362019-05-06T01:37:57  <luke-jr> tryphe: I don't think C++ allows it to be ambiguous
 372019-05-06T01:38:35  *** cornfeedhobo has quit IRC
 382019-05-06T01:40:22  *** scoop has quit IRC
 392019-05-06T01:42:36  *** cornfeedhobo has joined #bitcoin-core-dev
 402019-05-06T01:44:27  <sipa> tryphe: thabkfully we have a lot of control over supported platforms; right now, the code already relies on int being at least 32 bits iirc
 412019-05-06T01:46:11  <tryphe> luke-jr, sipa, those are good points, i guess it just makes me think how ints were 16 bits on 16-bit processors and how over time there were problems because interpretation became loose
 422019-05-06T01:47:45  <luke-jr> tryphe: int is guaranteed to be at least 16-bit
 432019-05-06T01:52:14  <tryphe> what about using an already defined fixed-width type like int32_t?
 442019-05-06T01:52:37  <tryphe> would it be preferred over int?
 452019-05-06T01:53:28  <luke-jr> it really depends on what the code requires
 462019-05-06T01:53:39  <luke-jr> if it's just counting from 1 to 3, int is fine
 472019-05-06T01:54:02  <luke-jr> if it's iterating over an array, it should use size_t
 482019-05-06T01:54:04  <luke-jr> etc
 492019-05-06T01:54:30  <luke-jr> fixed-width types should only be used when there is a need for an exact width
 502019-05-06T01:55:18  <tryphe> but if you know it's 32 bits, then that's why C++11 standard made fixed-width types, for that exact reaason
 512019-05-06T01:55:18  *** jtimon has quit IRC
 522019-05-06T01:55:38  <tryphe> it just seems strange that you would use int to me, that's all
 532019-05-06T01:56:21  <luke-jr> `int` is the preferred integer type when 16-bits is sufficient
 542019-05-06T01:56:39  <luke-jr> the compiler will choose whatever width is best for the target platform
 552019-05-06T01:56:58  <luke-jr> eg, it will use 32-bit if 16-bit would entail extra overflow checks/handling
 562019-05-06T01:57:29  <tryphe> i thought you guys only supported platforms where it was 32 bits, though
 572019-05-06T01:59:00  <sipa> yes
 582019-05-06T02:00:54  <tryphe> luke-jr, but from what sipa said, it can only be 32, hence the confusion
 592019-05-06T02:01:04  <tryphe> so it can be 16 sometimes?
 602019-05-06T02:01:21  <sipa> tryphe: C++ only guarantees that ints are at least 16 bits
 612019-05-06T02:01:36  <sipa> bitcoin core only support platforms where it is 32
 622019-05-06T02:02:02  <tryphe> gotcha
 632019-05-06T02:03:12  <tryphe> i still don't see why you would want to use int, seems like a future rat's nest of problems
 642019-05-06T02:04:09  <sipa> really, it is not a big deal
 652019-05-06T02:04:23  <sipa> int is big enough for the constant 32, hence, it is enough
 662019-05-06T02:05:24  *** davec has quit IRC
 672019-05-06T02:05:27  *** Klox has quit IRC
 682019-05-06T02:07:22  <tryphe> i see why you would want to use that for promotion to an unsigned type, but i'm just thinking hypothetically i guess :p
 692019-05-06T02:08:10  <tryphe> maybe some guy in 100 years compiles an old bitcoin build on the new C++50 standard where ints are 128 bytes, or something, lol
 702019-05-06T02:08:18  <tryphe> bits even
 712019-05-06T02:08:27  <luke-jr> and it will still work
 722019-05-06T02:09:18  <luke-jr> because 32 is still 32 in 128-bit
 732019-05-06T02:09:25  <tryphe> yeah, you could even safely promote it to size_t_128 or something i guess :p
 742019-05-06T02:09:39  <tryphe> thanks, that makes sense
 752019-05-06T02:09:51  <tryphe> wasn't trying to nag, just didn't understand it
 762019-05-06T02:18:40  *** skyikot has joined #bitcoin-core-dev
 772019-05-06T02:22:08  *** dgenr8 has quit IRC
 782019-05-06T02:23:58  *** ccdle12 has quit IRC
 792019-05-06T02:24:39  *** ccdle12 has joined #bitcoin-core-dev
 802019-05-06T02:27:46  *** Klox has joined #bitcoin-core-dev
 812019-05-06T02:29:31  *** ccdle12 has quit IRC
 822019-05-06T02:30:41  *** fanquake has joined #bitcoin-core-dev
 832019-05-06T02:34:16  *** pinheadmz has joined #bitcoin-core-dev
 842019-05-06T02:42:18  *** scoop has joined #bitcoin-core-dev
 852019-05-06T02:51:30  *** drexl has quit IRC
 862019-05-06T02:55:01  <tryphe> i'm thankful for bitcoin because watching the development process helps amatuers like me not have such terrible C++ habits :o
 872019-05-06T03:00:01  *** cpow has quit IRC
 882019-05-06T03:02:22  *** Dean_Guss has joined #bitcoin-core-dev
 892019-05-06T03:04:26  *** DeanGuss has quit IRC
 902019-05-06T03:05:54  *** zacts has joined #bitcoin-core-dev
 912019-05-06T03:06:17  *** zacts is now known as Guest48929
 922019-05-06T03:08:09  *** EagleTM has joined #bitcoin-core-dev
 932019-05-06T03:09:24  *** Eagle[TM] has quit IRC
 942019-05-06T03:14:40  *** DeanWeen has joined #bitcoin-core-dev
 952019-05-06T03:16:19  *** Dean_Guss has quit IRC
 962019-05-06T03:19:22  *** Klox has quit IRC
 972019-05-06T03:19:38  *** Klox3 has joined #bitcoin-core-dev
 982019-05-06T03:43:25  *** jarthur has quit IRC
 992019-05-06T04:08:30  *** davterra has joined #bitcoin-core-dev
1002019-05-06T04:09:29  *** davterra has quit IRC
1012019-05-06T04:11:46  *** davterra has joined #bitcoin-core-dev
1022019-05-06T04:13:20  *** scoop has quit IRC
1032019-05-06T04:14:02  *** hebasto has joined #bitcoin-core-dev
1042019-05-06T04:24:51  *** hebasto has quit IRC
1052019-05-06T04:43:49  *** skyikot has quit IRC
1062019-05-06T04:46:51  *** justanotheruser has quit IRC
1072019-05-06T05:13:43  *** ccdle12 has joined #bitcoin-core-dev
1082019-05-06T05:18:41  *** rex4539 has quit IRC
1092019-05-06T05:30:03  *** EagleTM has quit IRC
1102019-05-06T05:30:44  *** pinheadmz has quit IRC
1112019-05-06T05:37:17  <jb55> gcc bugs... spooky
1122019-05-06T05:52:03  <gwillen> tryphe: one interesting note about int, is that it is the smallest type for which C/C++ will not perform integer promotion behind your back unless the arguments have different types
1132019-05-06T05:52:12  <gwillen> if you're smaller than int, you get promoted to int no matter what
1142019-05-06T05:52:31  <gwillen> once you're at int, you get left alone unless you need a promotion to make the operation possible
1152019-05-06T06:00:02  *** Guest48929 has quit IRC
1162019-05-06T06:04:18  *** fredcooke1 has joined #bitcoin-core-dev
1172019-05-06T06:13:53  *** scoop has joined #bitcoin-core-dev
1182019-05-06T06:15:20  <tryphe> gwillen, neat, thanks!
1192019-05-06T06:15:41  <tryphe> gwillen, i guess i had noticed that before, but never had a real explanation for it.
1202019-05-06T06:18:20  *** scoop has quit IRC
1212019-05-06T06:42:28  *** DeanWeen has quit IRC
1222019-05-06T07:03:35  *** promag has joined #bitcoin-core-dev
1232019-05-06T07:07:02  *** riperk has quit IRC
1242019-05-06T07:08:12  *** promag has quit IRC
1252019-05-06T07:23:25  *** roconnor has joined #bitcoin-core-dev
1262019-05-06T07:23:41  *** roconnor_ has quit IRC
1272019-05-06T07:28:51  *** chaus has quit IRC
1282019-05-06T07:36:58  *** Apocalyptic has quit IRC
1292019-05-06T07:37:09  *** Apocalyptic has joined #bitcoin-core-dev
1302019-05-06T07:41:59  *** lukedashjr has joined #bitcoin-core-dev
1312019-05-06T07:42:45  *** EagleTM has joined #bitcoin-core-dev
1322019-05-06T07:42:51  *** luke-jr has quit IRC
1332019-05-06T07:45:33  *** DeanGuss has joined #bitcoin-core-dev
1342019-05-06T07:46:27  *** lukedashjr is now known as luke-jr
1352019-05-06T07:59:40  *** fanquake has quit IRC
1362019-05-06T08:05:20  *** bitcoin-git has joined #bitcoin-core-dev
1372019-05-06T08:05:21  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d7d7d3150606...9bbaac73bb1f
1382019-05-06T08:05:21  <bitcoin-git> bitcoin/master 77851ab Luke Dashjr: GUI: Refactor actual QR code rendering into new QRImageWidget::setQR
1392019-05-06T08:05:22  <bitcoin-git> bitcoin/master fc92984 Luke Dashjr: GUI: Move QRImageWidget to its own file-pair
1402019-05-06T08:05:22  <bitcoin-git> bitcoin/master 9bbaac7 Wladimir J. van der Laan: Merge #15928: GUI: Move QRImageWidget to its own file-pair
1412019-05-06T08:05:24  *** bitcoin-git has left #bitcoin-core-dev
1422019-05-06T08:06:05  *** bitcoin-git has joined #bitcoin-core-dev
1432019-05-06T08:06:05  <bitcoin-git> [bitcoin] laanwj merged pull request #15928:  GUI: Move QRImageWidget to its own file-pair (master...split_qrencoder) https://github.com/bitcoin/bitcoin/pull/15928
1442019-05-06T08:06:17  *** bitcoin-git has left #bitcoin-core-dev
1452019-05-06T08:08:00  *** bitcoin-git has joined #bitcoin-core-dev
1462019-05-06T08:08:01  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9bbaac73bb1f...773e16f9190f
1472019-05-06T08:08:01  <bitcoin-git> bitcoin/master 00d1104 Daniel Kraft: Install bitcoin-wallet manpage.
1482019-05-06T08:08:02  <bitcoin-git> bitcoin/master 773e16f Wladimir J. van der Laan: Merge #15947: Install bitcoin-wallet manpage
1492019-05-06T08:08:04  *** bitcoin-git has left #bitcoin-core-dev
1502019-05-06T08:08:06  *** ccdle12 has quit IRC
1512019-05-06T08:08:38  *** bitcoin-git has joined #bitcoin-core-dev
1522019-05-06T08:08:38  <bitcoin-git> [bitcoin] laanwj merged pull request #15947: Install bitcoin-wallet manpage (master...install-wallet-man) https://github.com/bitcoin/bitcoin/pull/15947
1532019-05-06T08:08:39  *** bitcoin-git has left #bitcoin-core-dev
1542019-05-06T08:11:12  *** setpill has joined #bitcoin-core-dev
1552019-05-06T08:19:09  *** chaus has joined #bitcoin-core-dev
1562019-05-06T08:22:37  *** spinza has quit IRC
1572019-05-06T08:26:43  *** ralphaaboy has joined #bitcoin-core-dev
1582019-05-06T08:28:31  *** ralphaaboy has quit IRC
1592019-05-06T08:30:09  *** promag has joined #bitcoin-core-dev
1602019-05-06T08:34:43  *** shesek has joined #bitcoin-core-dev
1612019-05-06T08:34:43  *** shesek has joined #bitcoin-core-dev
1622019-05-06T08:35:02  *** fredcooke1 has quit IRC
1632019-05-06T08:39:54  *** spinza has joined #bitcoin-core-dev
1642019-05-06T08:40:55  *** fanquake has joined #bitcoin-core-dev
1652019-05-06T08:42:39  *** chaus has quit IRC
1662019-05-06T08:44:06  *** andyvk5 has joined #bitcoin-core-dev
1672019-05-06T08:48:44  *** rex4539 has joined #bitcoin-core-dev
1682019-05-06T09:00:01  *** andyvk5 has quit IRC
1692019-05-06T09:11:58  *** Guyver2 has joined #bitcoin-core-dev
1702019-05-06T09:13:09  *** ccdle12 has joined #bitcoin-core-dev
1712019-05-06T09:19:22  *** chaus has joined #bitcoin-core-dev
1722019-05-06T09:23:01  *** chaus has quit IRC
1732019-05-06T09:23:43  *** rex4539 has quit IRC
1742019-05-06T09:37:24  *** bitcoin-git has joined #bitcoin-core-dev
1752019-05-06T09:37:25  <bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/773e16f9190f...a3d2d6b0674c
1762019-05-06T09:37:25  <bitcoin-git> bitcoin/master fad40ec MarcoFalke: wallet: Use IsValidNumArgs in getwalletinfo rpc
1772019-05-06T09:37:26  <bitcoin-git> bitcoin/master fad13e9 MarcoFalke: rpcwallet: Make helper methods const on CWallet
1782019-05-06T09:37:26  <bitcoin-git> bitcoin/master 999931c MarcoFalke: rpc: Add getbalances RPC
1792019-05-06T09:37:29  *** bitcoin-git has left #bitcoin-core-dev
1802019-05-06T09:38:07  *** bitcoin-git has joined #bitcoin-core-dev
1812019-05-06T09:38:07  <bitcoin-git> [bitcoin] laanwj merged pull request #15930: rpc: Add balances RPC (master...1904-rpcWalletBalances) https://github.com/bitcoin/bitcoin/pull/15930
1822019-05-06T09:38:08  *** bitcoin-git has left #bitcoin-core-dev
1832019-05-06T09:39:41  *** timothy has joined #bitcoin-core-dev
1842019-05-06T09:40:27  *** Skirmant has joined #bitcoin-core-dev
1852019-05-06T09:50:28  *** chaus has joined #bitcoin-core-dev
1862019-05-06T09:53:00  *** chaus has quit IRC
1872019-05-06T10:00:43  *** chaus has joined #bitcoin-core-dev
1882019-05-06T10:03:18  *** benj1 has joined #bitcoin-core-dev
1892019-05-06T10:08:19  *** chaus has quit IRC
1902019-05-06T10:12:40  *** chaus has joined #bitcoin-core-dev
1912019-05-06T10:14:14  *** scoop has joined #bitcoin-core-dev
1922019-05-06T10:15:49  *** queip has quit IRC
1932019-05-06T10:16:29  *** rafalcpp_ has joined #bitcoin-core-dev
1942019-05-06T10:16:45  *** rafalcpp has quit IRC
1952019-05-06T10:18:23  *** scoop has quit IRC
1962019-05-06T10:29:20  *** jonatack has joined #bitcoin-core-dev
1972019-05-06T10:30:01  *** rex4539 has joined #bitcoin-core-dev
1982019-05-06T10:34:46  *** queip has joined #bitcoin-core-dev
1992019-05-06T10:36:21  *** rex4539 has quit IRC
2002019-05-06T10:36:41  *** benj1 has quit IRC
2012019-05-06T10:37:02  *** rex4539 has joined #bitcoin-core-dev
2022019-05-06T10:38:52  *** ccdle12_ has joined #bitcoin-core-dev
2032019-05-06T10:38:58  *** spinza has quit IRC
2042019-05-06T10:41:22  *** ccdle12 has quit IRC
2052019-05-06T10:45:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2062019-05-06T10:46:01  *** spinza has joined #bitcoin-core-dev
2072019-05-06T10:48:21  *** shesek has quit IRC
2082019-05-06T11:09:07  *** AaronvanW has joined #bitcoin-core-dev
2092019-05-06T11:10:41  *** chaus has quit IRC
2102019-05-06T11:18:38  *** Guest48528 has joined #bitcoin-core-dev
2112019-05-06T11:38:49  *** bitcoin-git has joined #bitcoin-core-dev
2122019-05-06T11:38:49  <bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/a3d2d6b0674c...c5ffe8d5155b
2132019-05-06T11:38:50  <bitcoin-git> bitcoin/master 2ee811e João Barbosa: wallet: Track scanning duration
2142019-05-06T11:38:50  <bitcoin-git> bitcoin/master 90e27ab João Barbosa: wallet: Track current scanning progress
2152019-05-06T11:38:50  <bitcoin-git> bitcoin/master d3e8458 João Barbosa: rpc: Show scanning details in getwalletinfo
2162019-05-06T11:38:52  *** bitcoin-git has left #bitcoin-core-dev
2172019-05-06T11:39:24  *** bitcoin-git has joined #bitcoin-core-dev
2182019-05-06T11:39:24  <bitcoin-git> [bitcoin] laanwj merged pull request #15730: rpc: Show scanning details in getwalletinfo (master...2019-04-getwalletinfo-scanning) https://github.com/bitcoin/bitcoin/pull/15730
2192019-05-06T11:39:26  *** bitcoin-git has left #bitcoin-core-dev
2202019-05-06T11:39:43  *** chaus has joined #bitcoin-core-dev
2212019-05-06T11:44:27  *** chaus has quit IRC
2222019-05-06T11:45:11  *** bitcoin-git has joined #bitcoin-core-dev
2232019-05-06T11:45:11  <bitcoin-git> [bitcoin] meshcollider opened pull request #15957: Show "No wallets available" in open menu instead of nothing (master...201905_openwallet_empty) https://github.com/bitcoin/bitcoin/pull/15957
2242019-05-06T11:45:23  *** bitcoin-git has left #bitcoin-core-dev
2252019-05-06T11:46:34  *** chaus has joined #bitcoin-core-dev
2262019-05-06T11:52:27  *** Chris_Stewart_5 has quit IRC
2272019-05-06T12:00:02  *** Guest48528 has quit IRC
2282019-05-06T12:05:14  *** belcher has joined #bitcoin-core-dev
2292019-05-06T12:05:52  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2302019-05-06T12:05:56  *** jtimon has joined #bitcoin-core-dev
2312019-05-06T12:13:08  *** shesek has joined #bitcoin-core-dev
2322019-05-06T12:32:28  *** promag has quit IRC
2332019-05-06T12:33:18  *** secdragon has joined #bitcoin-core-dev
2342019-05-06T12:35:03  *** justanotheruser has joined #bitcoin-core-dev
2352019-05-06T12:44:47  *** chaus has quit IRC
2362019-05-06T12:46:25  *** chaus has joined #bitcoin-core-dev
2372019-05-06T12:51:22  *** chaus has quit IRC
2382019-05-06T13:04:53  *** promag has joined #bitcoin-core-dev
2392019-05-06T13:07:07  *** shesek has quit IRC
2402019-05-06T13:07:08  *** drexl has joined #bitcoin-core-dev
2412019-05-06T13:09:10  *** promag has quit IRC
2422019-05-06T13:11:22  *** DeanGuss has quit IRC
2432019-05-06T13:12:04  *** DeanGuss has joined #bitcoin-core-dev
2442019-05-06T13:18:17  *** Chris_Stewart_5 has quit IRC
2452019-05-06T13:19:23  *** drexl has quit IRC
2462019-05-06T13:20:00  *** jonatack has quit IRC
2472019-05-06T13:29:59  *** EagleTM has quit IRC
2482019-05-06T13:30:38  *** promag has joined #bitcoin-core-dev
2492019-05-06T13:40:10  *** shesek has joined #bitcoin-core-dev
2502019-05-06T13:40:10  *** shesek has joined #bitcoin-core-dev
2512019-05-06T13:41:10  *** spaced0ut has quit IRC
2522019-05-06T13:41:39  *** fasfasdfasfd has joined #bitcoin-core-dev
2532019-05-06T13:45:03  *** fasfasdfasfd has quit IRC
2542019-05-06T13:45:14  *** scoop has joined #bitcoin-core-dev
2552019-05-06T13:47:58  *** Mirko_ has joined #bitcoin-core-dev
2562019-05-06T13:49:47  *** scoop has quit IRC
2572019-05-06T13:52:54  *** chaus has joined #bitcoin-core-dev
2582019-05-06T13:56:03  *** promag_ has joined #bitcoin-core-dev
2592019-05-06T13:57:15  *** chaus has quit IRC
2602019-05-06T13:58:47  *** spaced0ut has joined #bitcoin-core-dev
2612019-05-06T14:03:32  *** davterra has quit IRC
2622019-05-06T14:03:51  *** rex4539 has quit IRC
2632019-05-06T14:09:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2642019-05-06T14:19:25  *** bitcoin-git has joined #bitcoin-core-dev
2652019-05-06T14:19:25  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15959: refactor: Work around gcc compiler bug 90348 (master...1905-gccBugWorkaround) https://github.com/bitcoin/bitcoin/pull/15959
2662019-05-06T14:19:26  *** bitcoin-git has left #bitcoin-core-dev
2672019-05-06T14:25:00  *** dfsg has joined #bitcoin-core-dev
2682019-05-06T14:25:42  *** dfsg has left #bitcoin-core-dev
2692019-05-06T14:31:33  *** afk11 has joined #bitcoin-core-dev
2702019-05-06T14:34:21  *** chaus has joined #bitcoin-core-dev
2712019-05-06T14:50:29  *** pinheadmz has joined #bitcoin-core-dev
2722019-05-06T15:00:01  *** secdragon has quit IRC
2732019-05-06T15:04:47  *** manuel3 has joined #bitcoin-core-dev
2742019-05-06T15:09:19  *** scoop has joined #bitcoin-core-dev
2752019-05-06T15:10:26  *** IGHOR has quit IRC
2762019-05-06T15:13:56  *** scoop has quit IRC
2772019-05-06T15:14:27  *** IGHOR has joined #bitcoin-core-dev
2782019-05-06T15:15:50  *** promag_ has quit IRC
2792019-05-06T15:17:02  *** setpill has quit IRC
2802019-05-06T15:18:51  *** spaced0ut has quit IRC
2812019-05-06T15:21:57  *** dcousens has quit IRC
2822019-05-06T15:22:45  *** spaced0ut has joined #bitcoin-core-dev
2832019-05-06T15:23:35  *** dcousens has joined #bitcoin-core-dev
2842019-05-06T15:27:07  *** Emcy has quit IRC
2852019-05-06T15:28:05  *** dcousens has quit IRC
2862019-05-06T15:34:21  *** bitcoin-git has joined #bitcoin-core-dev
2872019-05-06T15:34:22  <bitcoin-git> [bitcoin] Annasadra opened pull request #15960: git (master...master) https://github.com/bitcoin/bitcoin/pull/15960
2882019-05-06T15:34:27  *** bitcoin-git has left #bitcoin-core-dev
2892019-05-06T15:34:45  *** dcousens has joined #bitcoin-core-dev
2902019-05-06T15:39:03  *** jonatack has joined #bitcoin-core-dev
2912019-05-06T15:39:43  *** Emcy has joined #bitcoin-core-dev
2922019-05-06T15:40:02  *** chaus has quit IRC
2932019-05-06T15:40:35  *** scoop has joined #bitcoin-core-dev
2942019-05-06T15:43:15  *** Mirko_ has quit IRC
2952019-05-06T15:43:20  *** spinza has quit IRC
2962019-05-06T15:44:37  *** scoop has quit IRC
2972019-05-06T15:55:11  *** drexl has joined #bitcoin-core-dev
2982019-05-06T15:56:47  *** scoop has joined #bitcoin-core-dev
2992019-05-06T15:57:54  *** rex4539 has joined #bitcoin-core-dev
3002019-05-06T15:59:20  *** spinza has joined #bitcoin-core-dev
3012019-05-06T15:59:24  *** dcousens has quit IRC
3022019-05-06T15:59:48  *** scoop_ has joined #bitcoin-core-dev
3032019-05-06T15:59:56  *** scoop has quit IRC
3042019-05-06T16:00:21  *** scoop has joined #bitcoin-core-dev
3052019-05-06T16:03:18  *** ccdle12_ has quit IRC
3062019-05-06T16:04:11  *** scoop_ has quit IRC
3072019-05-06T16:08:42  *** bitcoin-git has joined #bitcoin-core-dev
3082019-05-06T16:08:42  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15960: git (master...master) https://github.com/bitcoin/bitcoin/pull/15960
3092019-05-06T16:08:44  *** bitcoin-git has left #bitcoin-core-dev
3102019-05-06T16:11:15  *** chaus has joined #bitcoin-core-dev
3112019-05-06T16:16:04  *** chaus has quit IRC
3122019-05-06T16:36:59  *** bitcoin-git has joined #bitcoin-core-dev
3132019-05-06T16:36:59  <bitcoin-git> [bitcoin] practicalswift opened pull request #15962: Add locking annotation for RewindBlockIndex (requires holding cs_main) (master...RewindBlockIndex) https://github.com/bitcoin/bitcoin/pull/15962
3142019-05-06T16:37:05  *** bitcoin-git has left #bitcoin-core-dev
3152019-05-06T16:46:43  *** roconnor_ has joined #bitcoin-core-dev
3162019-05-06T16:47:19  *** roconnor has quit IRC
3172019-05-06T16:52:12  *** davec has joined #bitcoin-core-dev
3182019-05-06T16:53:31  *** scoop has quit IRC
3192019-05-06T16:54:00  *** scoop has joined #bitcoin-core-dev
3202019-05-06T16:56:02  *** scoop has quit IRC
3212019-05-06T16:56:09  *** scoop has joined #bitcoin-core-dev
3222019-05-06T17:01:11  *** bitcoin-git has joined #bitcoin-core-dev
3232019-05-06T17:01:12  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c5ffe8d5155b...8ec7121a4590
3242019-05-06T17:01:12  <bitcoin-git> bitcoin/master ba534cc John Newbery: [tests] log thread names by default in functional tests
3252019-05-06T17:01:13  <bitcoin-git> bitcoin/master 7b29ec2 John Newbery: [tests] Comment for why logging config is set as command-line args.
3262019-05-06T17:01:13  <bitcoin-git> bitcoin/master 8ec7121 MarcoFalke: Merge #15927: [tests] log thread names by default in functional tests
3272019-05-06T17:01:15  *** bitcoin-git has left #bitcoin-core-dev
3282019-05-06T17:01:54  *** bitcoin-git has joined #bitcoin-core-dev
3292019-05-06T17:01:54  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15927: [tests] log thread names by default in functional tests (master...2019-04-log-threads-tests) https://github.com/bitcoin/bitcoin/pull/15927
3302019-05-06T17:01:55  *** bitcoin-git has left #bitcoin-core-dev
3312019-05-06T17:02:21  *** promag_ has joined #bitcoin-core-dev
3322019-05-06T17:17:41  *** chaus has joined #bitcoin-core-dev
3332019-05-06T17:19:33  *** bitcoin-git has joined #bitcoin-core-dev
3342019-05-06T17:19:33  <bitcoin-git> [bitcoin] jnewbery opened pull request #15963: [tests] Make random seed logged and settable (master...2019-05-test-deterministic-randomness) https://github.com/bitcoin/bitcoin/pull/15963
3352019-05-06T17:19:34  *** bitcoin-git has left #bitcoin-core-dev
3362019-05-06T17:20:25  *** jarthur has joined #bitcoin-core-dev
3372019-05-06T17:22:13  *** chaus has quit IRC
3382019-05-06T17:22:55  *** Chris_Stewart_5 has quit IRC
3392019-05-06T17:27:58  *** chaus has joined #bitcoin-core-dev
3402019-05-06T17:34:00  *** davterra has joined #bitcoin-core-dev
3412019-05-06T17:40:18  *** omonk has quit IRC
3422019-05-06T17:41:10  *** omonk has joined #bitcoin-core-dev
3432019-05-06T17:51:09  *** belcher has quit IRC
3442019-05-06T17:52:09  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3452019-05-06T17:57:26  *** scoop has quit IRC
3462019-05-06T17:57:52  *** scoop has joined #bitcoin-core-dev
3472019-05-06T17:59:24  *** dgenr8 has joined #bitcoin-core-dev
3482019-05-06T18:00:02  *** manuel3 has quit IRC
3492019-05-06T18:00:25  *** hebasto has joined #bitcoin-core-dev
3502019-05-06T18:02:14  *** scoop has quit IRC
3512019-05-06T18:04:09  *** obsrver has joined #bitcoin-core-dev
3522019-05-06T18:06:14  *** Suntop1 has joined #bitcoin-core-dev
3532019-05-06T18:18:51  *** Chris_Stewart_5 has quit IRC
3542019-05-06T18:21:52  *** _Sam-- has joined #bitcoin-core-dev
3552019-05-06T18:22:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3562019-05-06T18:24:32  *** promag_ has quit IRC
3572019-05-06T18:30:11  *** jarthur_ has joined #bitcoin-core-dev
3582019-05-06T18:33:48  *** jarthur has quit IRC
3592019-05-06T18:35:09  *** user2019 has joined #bitcoin-core-dev
3602019-05-06T18:37:57  *** bitcoin-git has joined #bitcoin-core-dev
3612019-05-06T18:37:58  <bitcoin-git> [bitcoin] giulio92 opened pull request #15964: Docs: Improve build-osx document formatting (master...feature/update-macOS-doc) https://github.com/bitcoin/bitcoin/pull/15964
3622019-05-06T18:37:59  *** bitcoin-git has left #bitcoin-core-dev
3632019-05-06T18:55:29  <tryphe> if the default maximum open file descriptors on Mac OS 10 is 256 ('ulimit -n' == 256), and the leveldb default is 1000, what would a reasonable leveldb default be so that bitcoind + leveldb won't exceed 256 fds total?
3642019-05-06T18:56:10  <tryphe> on one hand, if it goes too low, it could hurt performance, but on the other hand, we don't want it to exceed 256, which seems low for having tons of files around for compaction.
3652019-05-06T18:57:14  <tryphe> i guess i should clarify: it's 256 per process, not system-wide, of course.
3662019-05-06T18:59:04  <gwillen> tryphe: have you actually hit the limit?
3672019-05-06T18:59:06  <luke-jr> is it really? :/
3682019-05-06T18:59:12  <gwillen> I'm asking because I'm on OS X and I'm kind of suprised I never have
3692019-05-06T18:59:17  <gwillen> luke-jr: yes, it sucks
3702019-05-06T18:59:30  <luke-jr> including mmaps?
3712019-05-06T18:59:32  <gwillen> I had to change one of the linter tests because it tried to open every file in the tree at once, and it would crash on OS X
3722019-05-06T18:59:40  <gwillen> mm, I don't know about mmaps, I wouldn't think so
3732019-05-06T18:59:44  <gwillen> maybe that's why I've never hit it?
3742019-05-06T19:00:13  <tryphe> ^ i was looking at #14870 and realized this was most likely the culprit after running ulimit
3752019-05-06T19:00:15  <gribble> https://github.com/bitcoin/bitcoin/issues/14870 | Bitcoind crashes with Too Many Files error · Issue #14870 · bitcoin/bitcoin · GitHub
3762019-05-06T19:00:57  <tryphe> but it's hard to know how many files will need to be read by the compaction mechanism... i doubt it's identical across different configurations and whatnot
3772019-05-06T19:01:38  <tryphe> read simultaneously, rather
3782019-05-06T19:02:20  <gwillen> the change that raised the leveldb limit to 1000 is https://github.com/bitcoin/bitcoin/pull/12495
3792019-05-06T19:02:29  <gwillen> which says (like luke-jr was just asking): "On 64-bit POSIX hosts LevelDB will open up to 1000 file descriptors using mmap(), and it does not retain an open file descriptor for such files."
3802019-05-06T19:02:36  <tryphe> gwillen, i didn't hit the limit personally, but my Mac box is mostly just for testing, not for full node running
3812019-05-06T19:02:51  <gwillen> so I wonder if something else is actually the culprit
3822019-05-06T19:03:02  <gwillen> I regularly run full nodes on my box for testing and real use
3832019-05-06T19:03:05  <gwillen> and I've _never_ hit this
3842019-05-06T19:03:12  *** jarthur_ has quit IRC
3852019-05-06T19:03:28  <gwillen> although I guess these days I wouldn't, since I upped my default at some point... if I did that before 12495 was merged, I might be a bad test case
3862019-05-06T19:03:49  *** jarthur has joined #bitcoin-core-dev
3872019-05-06T19:03:55  <gwillen> but I would expect that if the leveldb file count were the culprit, LOTS of people would be affected, and I believe the theory that mmaps should not count
3882019-05-06T19:06:11  <tryphe> yeah, i'm not sure. my hunch was that leveldb would approach that limit, and bitcoind opening files could cause the issue to appear, without leveldb being the sole cause (depends how many files bitcoind is also accessing)
3892019-05-06T19:06:46  <tryphe> which would make sense i guess, 256 isn't insanely high
3902019-05-06T19:09:11  *** scoop has joined #bitcoin-core-dev
3912019-05-06T19:14:04  *** chaus has quit IRC
3922019-05-06T19:14:06  *** waxwing has quit IRC
3932019-05-06T19:14:56  *** EagleTM has joined #bitcoin-core-dev
3942019-05-06T19:19:45  *** waxwing has joined #bitcoin-core-dev
3952019-05-06T19:24:01  *** jarthur has quit IRC
3962019-05-06T19:25:49  *** obsrver has quit IRC
3972019-05-06T19:27:44  *** chaus has joined #bitcoin-core-dev
3982019-05-06T19:32:32  *** promag_ has joined #bitcoin-core-dev
3992019-05-06T19:34:02  *** jarthur has joined #bitcoin-core-dev
4002019-05-06T19:34:34  *** jarthur has joined #bitcoin-core-dev
4012019-05-06T19:34:38  *** bitcoin-git has joined #bitcoin-core-dev
4022019-05-06T19:34:38  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8ec7121a4590...3632143ebbfd
4032019-05-06T19:34:38  <bitcoin-git> bitcoin/master d2eee87 Ben Woosley: Lift prevector default vals to the member declaration
4042019-05-06T19:34:39  <bitcoin-git> bitcoin/master 3632143 MarcoFalke: Merge #14266: refactor: Lift prevector default vals to the member declarat...
4052019-05-06T19:34:40  *** bitcoin-git has left #bitcoin-core-dev
4062019-05-06T19:34:40  *** michagogo_ has joined #bitcoin-core-dev
4072019-05-06T19:34:53  *** bitcoin-git has joined #bitcoin-core-dev
4082019-05-06T19:34:53  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #14266: refactor: Lift prevector default vals to the member declaration (master...prevector-defaults) https://github.com/bitcoin/bitcoin/pull/14266
4092019-05-06T19:34:54  *** bitcoin-git has left #bitcoin-core-dev
4102019-05-06T19:35:14  *** roconnor has joined #bitcoin-core-dev
4112019-05-06T19:35:17  *** rafalcpp has joined #bitcoin-core-dev
4122019-05-06T19:35:41  *** jonny_osaka has joined #bitcoin-core-dev
4132019-05-06T19:35:41  *** scoop_ has joined #bitcoin-core-dev
4142019-05-06T19:38:31  <gmaxwell> gwillen: bitcoin increases the ulimit, see RaiseFileDescriptorLimit().
4152019-05-06T19:38:43  *** jarthur has quit IRC
4162019-05-06T19:38:51  *** belcher has joined #bitcoin-core-dev
4172019-05-06T19:39:19  <gmaxwell> mmaps also don't themselves count. (also most of the time any 'large' malloc also results in a mmap)
4182019-05-06T19:39:24  *** cornfeedhobo has quit IRC
4192019-05-06T19:39:25  *** Apocalyptic has quit IRC
4202019-05-06T19:39:25  *** promag has quit IRC
4212019-05-06T19:39:25  *** owowo has quit IRC
4222019-05-06T19:39:25  *** scoop has quit IRC
4232019-05-06T19:39:25  *** roconnor_ has quit IRC
4242019-05-06T19:39:25  *** Emcy has quit IRC
4252019-05-06T19:39:25  *** spaced0ut has quit IRC
4262019-05-06T19:39:25  *** rafalcpp_ has quit IRC
4272019-05-06T19:39:26  *** michagogo has quit IRC
4282019-05-06T19:39:33  *** michagogo_ is now known as michagogo
4292019-05-06T19:39:50  *** ovovo has joined #bitcoin-core-dev
4302019-05-06T19:40:12  *** Emcy has joined #bitcoin-core-dev
4312019-05-06T19:40:16  *** Apocalyptic has joined #bitcoin-core-dev
4322019-05-06T19:42:21  *** chaus has quit IRC
4332019-05-06T19:54:06  *** cornfeedhobo has joined #bitcoin-core-dev
4342019-05-06T19:58:36  <tryphe> gmaxwell, it looks like it would call RaiseFileDescriptorLimit(125 + 150 + 8), which only gets you 283 instead of 256
4352019-05-06T19:59:01  <tryphe> gmaxwell: https://github.com/bitcoin/bitcoin/blob/12aa2ac988d0ccb21019a20b109e018cf31b78cf/src/init.cpp#L1007
4362019-05-06T19:59:20  <sipa> tryphe: on 64-bit systems, LevelDB uses mmap which doesn't need many simultaneous file descriptors
4372019-05-06T19:59:21  <tryphe> and on linux, it's less than 1024, which is the default, so it does nothing
4382019-05-06T20:02:27  <gwillen> right, if leveldb isn't taking up fds then the whole leveldb thing is a red herring and the cause must be something else
4392019-05-06T20:02:52  <tryphe> sipa, i see, but what about too many concurrent mmap() calls? assuming you have a bunch of 2MB files at one level, it seems to me like you could potentially still be opening hundreds of handles at once
4402019-05-06T20:03:26  *** drexl_ has joined #bitcoin-core-dev
4412019-05-06T20:03:41  *** spaced0ut has joined #bitcoin-core-dev
4422019-05-06T20:04:15  <tryphe> sipa, what i mean by that is, the fd isn't closed until mmap returns the mapping
4432019-05-06T20:04:40  <gmaxwell> tryphe: yes, but they are created sequentially.
4442019-05-06T20:04:40  <sipa> tryphe: i don't think those things happen in separate threads
4452019-05-06T20:05:12  <tryphe> i see, thanks. maybe i'm thinking of rocksdb, where it happens in a thread pool.
4462019-05-06T20:05:18  <gmaxwell> the comment about RPC in the reporter is a pretty strong indication that they're likely hammering the RPC...
4472019-05-06T20:05:54  <tryphe> gmaxwell, yeah, but usually you don't have leveldb throw that error unless something is implemented wrong, it's a common problem
4482019-05-06T20:06:54  *** drexl has quit IRC
4492019-05-06T20:07:44  <gmaxwell> tryphe: the error being reported by the user is not from leveldb.
4502019-05-06T20:07:55  <gmaxwell> It's from libevent-- which handles the rpc.
4512019-05-06T20:09:52  <tryphe> gmaxwell, look at the first instance
4522019-05-06T20:09:53  <gmaxwell> tryphe: it looks to me like they're hammering the rpc and used up all the FDs that way, and leveldb is unable to get a single FD to open a file.
4532019-05-06T20:10:11  <tryphe> gmaxwell, 2018-12-04T17:09:42Z leveldb: Compaction error: IO error: /Users/matt/Library/Application Support/Bitcoin/testnet3/indexes/txindex/012589.ldb: Too many open files
4542019-05-06T20:11:00  <sipa> maybe we should increasy fds also proportionally to -rpcthreads ?
4552019-05-06T20:11:51  *** jonny_osaka has quit IRC
4562019-05-06T20:12:43  <gmaxwell> sipa: yes, I was just looking for where we did that, seems we don't.
4572019-05-06T20:13:38  <gmaxwell> we might want to add some instrumentation that runs during tests, and checks to see if the total open fds is ever greater than we pass to RaiseFileDescriptorLimit.
4582019-05-06T20:13:59  <tryphe> if it raises the fds to 283 if it's <283, but the default is 1024 on most linux/unix systems (except mac os), would a sane thing to be just to increase the fds to 1024 on mac os? (i think the max per process is 10240)
4592019-05-06T20:14:02  <gmaxwell> otherwise we're going to keep ending up with bugs that are invisible when RaiseFileDescriptorLimit does nothing.
4602019-05-06T20:14:35  <gmaxwell> tryphe: well that would just be covering up the bug that RaiseFileDescriptorLimit isn't being increased by the rpc thread count.
4612019-05-06T20:16:00  <tryphe> gmaxwell, yeah, i'm not even sure how to reproduce it, but if that's one glaring difference, it might make sense to increase it?
4622019-05-06T20:16:49  <gmaxwell> tryphe: then the problem will just show up again when users set rpcthreads even higher
4632019-05-06T20:17:15  <gmaxwell> if you don't understand an issue, just changing things blindly risks introducing new issues, and not fixing them.
4642019-05-06T20:17:44  <gmaxwell> But I think we do understand it-- RaiseFileDescriptorLimit should be getting the rpcthreads added.
4652019-05-06T20:17:57  <sipa> but by how much?
4662019-05-06T20:18:12  <tryphe> gmaxwell, i don't see how adding in the number of rpcs would do anything if RaiseFileDescriptorLimit() doesn't do anything if my fd limit is 1024 by default
4672019-05-06T20:18:19  <tryphe> rpcs/rpc threads
4682019-05-06T20:18:29  *** bitcoin-git has joined #bitcoin-core-dev
4692019-05-06T20:18:29  <bitcoin-git> [bitcoin] zenosage opened pull request #15965: check bad-prevblk is right error for invalid descendants (master...bad-prevblk) https://github.com/bitcoin/bitcoin/pull/15965
4702019-05-06T20:18:30  *** bitcoin-git has left #bitcoin-core-dev
4712019-05-06T20:20:28  *** Guyver2 has quit IRC
4722019-05-06T20:20:28  <gmaxwell> tryphe: go look at the code in init.cpp. It works out how many FDs we can actually use.
4732019-05-06T20:20:32  <sipa> tryphe: what if you have 2000 rpc threads? :)
4742019-05-06T20:21:17  <gmaxwell> Right now it doesn't account for the RPC threads (they're just assumed to be part of MIN_CORE_FILEDESCRIPTORS, but that doesn't hold if someone changes the setting)
4752019-05-06T20:21:23  <gmaxwell> it should account for RPC threads.
4762019-05-06T20:21:37  <gmaxwell> Which would be the actual bug.
4772019-05-06T20:22:52  *** promag has joined #bitcoin-core-dev
4782019-05-06T20:23:59  <tryphe> gmaxwell, i already looked at it before i told you anything
4792019-05-06T20:24:58  <sipa> tryphe: i think you're missing something, but i don't see what
4802019-05-06T20:25:52  <tryphe> i see why you would want to add the number of rpc threads, but not why you would want different fd max values on different systems
4812019-05-06T20:26:25  <sipa> what are you talking about with "different fd max values on different systems" ?
4822019-05-06T20:27:07  *** promag has quit IRC
4832019-05-06T20:27:14  <gmaxwell> sipa: he's referring to the fact that we don't raise it if it's already more than we need.
4842019-05-06T20:27:20  <tryphe> sipa, on mac os 10, if 'limit -n' gives 256, what would RaiseFileDescriptorLimit() set the value to?
4852019-05-06T20:27:37  <tryphe> sipa, likewise, on linux, what would it do?
4862019-05-06T20:27:46  <gmaxwell> sipa: and on OSX the default is lower than we need (with defaults), but on linux it's higher.
4872019-05-06T20:27:47  <sipa> it tries to raise it if needed
4882019-05-06T20:27:58  <tryphe> the difference is a value of ~700
4892019-05-06T20:27:59  <sipa> if it's not needed, there is nothing to be done
4902019-05-06T20:28:22  <sipa> yes, so the number needed is miscomputed, and we should fix that
4912019-05-06T20:28:23  <gmaxwell> tryphe: The limit is compltely irrelevant so long as it is greater than our need. If our caclulated need is incorrect, then we will have problems in some configurations.
4922019-05-06T20:28:33  <sipa> that fact that it's already 1024 only helps mask the problem
4932019-05-06T20:29:12  <gmaxwell> If we set the limit higher than we think we need, it won't fix any bugs-- the program will still fail in some configurations-- but it will make some bugs less visible.
4942019-05-06T20:29:55  <gmaxwell> So instead of failing on mac when you adjust rpc threads at all, it'll still fail, but everwhere when you set rpcthreads to 700. (or whatever)
4952019-05-06T20:30:13  <tryphe> right but <300 seems pretty low, especially if they are running bitcoin-qt which accesses a bunch of files, not to mention future features
4962019-05-06T20:30:30  <sipa> tryphe: so we should fix the computation that incorrectly determines 300 is enough
4972019-05-06T20:30:31  <gmaxwell> Any new features that use FDs need to increase the calculated limit.
4982019-05-06T20:30:37  <sipa> i don't understand what you're arguing for
4992019-05-06T20:30:54  <tryphe> sipa, because it's a glaring difference, and you're blowing it off like it's nothing
5002019-05-06T20:30:57  <gmaxwell> No fixed amount is safe, only computing the required amount is safe.
5012019-05-06T20:31:02  <sipa> tryphe: no...
5022019-05-06T20:31:03  <sipa> i'm not
5032019-05-06T20:31:04  <tryphe> for every 1 github issue there's 1000 morons that ignored it and stopped using it
5042019-05-06T20:31:22  <sipa> i
5052019-05-06T20:31:22  <tryphe> for the same reason
5062019-05-06T20:31:28  <gwillen> tryphe: we are statically computing the exact number of file descriptors we need, and raising the limit to that exact value, which we will never exceed, so there is never a reason for it to be higher
5072019-05-06T20:31:37  <gwillen> in this case, there is a bug, which is that we compute the wrong number
5082019-05-06T20:31:47  <gwillen> once the bug is fixed, there will again be no reason to ever raise the number
5092019-05-06T20:31:57  <gmaxwell> tryphe: I think we're failing to communicate here. I think we should fix the problem, which is now known in part thanks to your exploration.  We should not, however, paper over misbehavior as that can create much more serious issues.
5102019-05-06T20:32:35  <gwillen> it sounds like you believe that Core will sometimes open other file descriptors not accounted for here, but that is not supposed to ever happen, and would represent a bug
5112019-05-06T20:32:35  <gmaxwell> Fixing the calculation will fix the bug.  Blindly increasing the value on OSX will paper over the bug and any similar bug in the future but not actually fix it.
5122019-05-06T20:32:54  *** bitcoin-git has joined #bitcoin-core-dev
5132019-05-06T20:32:54  <bitcoin-git> [bitcoin] hebasto opened pull request #15966: net: Drop the ancient miniUPnPc API version support (master...20190506-drop-ancient-miniupnpc-api) https://github.com/bitcoin/bitcoin/pull/15966
5142019-05-06T20:32:55  <gmaxwell> what gwillen says. All FDs _must_ be accounted for.
5152019-05-06T20:32:59  *** bitcoin-git has left #bitcoin-core-dev
5162019-05-06T20:33:11  <gwillen> I think this is unusual, and it's much more typical for people to just give a high number and hope for the best
5172019-05-06T20:33:15  <tryphe> sipa, gmaxwell, gwillen, i see. that makes sense.
5182019-05-06T20:33:23  <gwillen> cool :-)
5192019-05-06T20:33:26  <sipa> yeah, we try to account for all resource usage
5202019-05-06T20:33:29  <gmaxwell> (it's a little less crtical now that we don't use select on linux, but they still need to be accounted for)
5212019-05-06T20:33:32  <sipa> disk, memory, cpu, fds
5222019-05-06T20:33:54  <gwillen> could we actually _lower_ it from 1024 on linux, instead of leaving it alone?
5232019-05-06T20:34:02  <gwillen> that would make this kind of thing show up much faster
5242019-05-06T20:34:10  <gwillen> rather than only happening on oddball os x
5252019-05-06T20:34:16  <sipa> yeah, perhaps
5262019-05-06T20:34:26  <gwillen> and it would satisfy tryphe's very reasonable desire that it be the same across platforms, which I think is a good thought :-)
5272019-05-06T20:34:27  <gmaxwell> we should at least in some test builds.
5282019-05-06T20:34:30  <tryphe> i do think it's sort of a hinderance that mac os is somehow bundled in with other "linux/unix" compile targets and has some funny differences, though.
5292019-05-06T20:34:37  <gwillen> yeah
5302019-05-06T20:34:48  <gwillen> as one of the few people actively developing on OS X, I agree ;-)
5312019-05-06T20:34:49  <tryphe> but yeah i think raising it is silly especially with mmap
5322019-05-06T20:34:52  <gmaxwell> like make one of the debug builds reduce fd limit to the computed amount.
5332019-05-06T20:35:20  <tryphe> i didn't intend to suggest raising it as a key argument, just nitpicking differences between systems i guess
5342019-05-06T20:36:15  <gmaxwell> difference between systems are good though-- without this one we wouldn't have found this issue until some other change increased usage to the point where it was making 1024 limit get busted.
5352019-05-06T20:36:37  <gmaxwell> which might have happened across the whole network at once
5362019-05-06T20:37:56  <gwillen> heh, that's an interesting point
5372019-05-06T20:38:02  <tryphe> yeah, i would think lowering it and dynamically setting it across all platforms would make sense, as you only really need to increase it if you are running some insane file server or something
5382019-05-06T20:38:14  <tryphe> and that's when you -need- overkill
5392019-05-06T20:38:19  <tryphe> here, you know what you need
5402019-05-06T20:38:22  <sipa> what does file server have to do with it?
5412019-05-06T20:38:26  <gwillen> I raised it in my .profile, I should maybe take that out :-\
5422019-05-06T20:38:31  <gwillen> since it masks any problem like this
5432019-05-06T20:38:33  <sipa> this limit is per process, not system wide
5442019-05-06T20:38:38  <gwillen> I did it so I could get the tests to run, but then I fixed the tests
5452019-05-06T20:39:46  <tryphe> sipa, it just as an example of extremes where people blindly raise the limit to 10000 or whatever :p
5462019-05-06T20:40:04  *** timothy has quit IRC
5472019-05-06T20:40:11  <tryphe> sipa, but in those cases they are maybe succombing to future DoS problems and whatnot
5482019-05-06T20:44:15  *** scoop_ has quit IRC
5492019-05-06T20:44:41  *** scoop has joined #bitcoin-core-dev
5502019-05-06T20:47:24  *** davec has quit IRC
5512019-05-06T20:48:54  *** scoop has quit IRC
5522019-05-06T20:51:44  <tryphe> gmaxwell, do you think i should give it a test with a lower MIN_CORE_FILEDESCRIPTORS value, and add the rpc threads in? maybe use 0 for MIN_CORE_FILEDESCRIPTORS instead of 150
5532019-05-06T20:52:34  *** davec has joined #bitcoin-core-dev
5542019-05-06T20:53:57  *** promag has joined #bitcoin-core-dev
5552019-05-06T20:54:07  <sipa> We certainly need a few FDs independent of RPC handling (including those for accessing block files, undo files, ...)
5562019-05-06T20:54:28  <tryphe> right, i'll give it a try! thanks
5572019-05-06T20:55:31  <sipa> i also don't know how many FDs we need per RPC, and it's hard to experimentally determine the upper bound as it depends on the type of RPCs
5582019-05-06T20:56:18  <sipa> but there is at least 1 for the TCP connection itself (except on windows, where sockets don't count as FDs...), and maybe 1 or 2 more for files that may be accessed for handling the RPC
5592019-05-06T21:00:01  *** Suntop1 has quit IRC
5602019-05-06T21:01:32  <tryphe> i see, because an rpc might trigger a file to be read?
5612019-05-06T21:02:31  <sipa> yes
5622019-05-06T21:05:22  *** Avelino has joined #bitcoin-core-dev
5632019-05-06T21:06:21  *** bitcoin-git has joined #bitcoin-core-dev
5642019-05-06T21:06:21  <bitcoin-git> [bitcoin] practicalswift closed pull request #15962: Add locking annotations for RewindBlockIndex and GetNetworkHashPS. Add missing locks. (master...RewindBlockIndex) https://github.com/bitcoin/bitcoin/pull/15962
5652019-05-06T21:06:23  *** bitcoin-git has left #bitcoin-core-dev
5662019-05-06T21:11:02  <tryphe> sipa, i wonder if an "rpc thread fd factor" could be used, perhaps to replace MIN_CORE_FILEDESCRIPTORS which is a value of 150. 20 fds per thread *8 threads=160, so you'd get 160, which is roughly the same, but a little more
5672019-05-06T21:11:34  <sipa> tryphe: we still have a number of fds independent of RPCs
5682019-05-06T21:11:39  <sipa> probably the majority
5692019-05-06T21:11:43  <tryphe> sipa, right, that's true
5702019-05-06T21:12:09  <tryphe> good point
5712019-05-06T21:15:50  *** Chris_Stewart_5 has quit IRC
5722019-05-06T21:17:46  <jamesob> anyone think it'd be a good idea to prefix class member function calls with `this->` for clarity?
5732019-05-06T21:18:56  <luke-jr> jamesob: no, that's why they're supposed to be named m_*
5742019-05-06T21:19:25  <jamesob> that only applies to class *data* members afaict
5752019-05-06T21:19:32  <luke-jr> oh, methods
5762019-05-06T21:20:26  <luke-jr> `this->` seems ugly, but I don't know that I have a better solution, and I agree it can at times be unclear
5772019-05-06T21:21:03  <jamesob> luke-jr: agreed
5782019-05-06T21:21:26  <sipa> jamesob: the explicit way to do that is writing Classname::Method(...)
5792019-05-06T21:21:33  <sipa> but that's also ugly
5802019-05-06T21:21:39  <tryphe> i think it makes a little sense if you consider how you destruct this->~Class();
5812019-05-06T21:21:44  <tryphe> but maybe adds clutter
5822019-05-06T21:22:00  <luke-jr> what?
5832019-05-06T21:22:17  <luke-jr> you destruct with delete..
5842019-05-06T21:22:23  <jamesob> sipa: yeah that's wordy
5852019-05-06T21:23:04  * luke-jr wonders why `this` is a pointer and not a reference anyway
5862019-05-06T21:23:23  <jamesob> something something destructors something something?
5872019-05-06T21:34:14  <sipa> http://www.stroustrup.com/bs_faq2.html#pointers-and-references
5882019-05-06T21:34:18  <sipa>  Why is "this" not a reference?
5892019-05-06T21:34:19  <sipa> Because "this" was introduced into C++ (really into C with Classes) before references were added. Also, I chose "this" to follow Simula usage, rather than the (later) Smalltalk use of "self".
5902019-05-06T21:34:45  <tryphe> luke-jr, they are identical, but you can use delete to destruct an array
5912019-05-06T21:35:00  <sipa> tryphe: no, you need delete[] to destruct an array
5922019-05-06T21:35:05  *** DeanGuss has quit IRC
5932019-05-06T21:35:10  <sipa> and invoking a destructor does not release its memory
5942019-05-06T21:35:17  <sipa> it only destroys the object allocated in it
5952019-05-06T21:36:00  <tryphe> sipa, that's what i said
5962019-05-06T21:36:53  <sipa> 1) "but you can use delete to destruct an array", that's wrong, you need to use delete[]
5972019-05-06T21:37:27  <tryphe> sipa, yeah.... i meant delete or delete[]
5982019-05-06T21:37:33  <sipa> 2) "they are identical", that's wrong; deleting an object invokes the relevant destructors as needed, but actually cleans up allocated memory
5992019-05-06T21:37:38  <tryphe> just 'delete' as the keyword
6002019-05-06T21:37:41  * luke-jr wonders if there's ever a case where calling this->~class directly actually makes sense. :x
6012019-05-06T21:38:33  <sipa> luke-jr: if you're constructing objects objects in self-allocated space
6022019-05-06T21:39:01  <sipa> https://github.com/bitcoin/bitcoin/blob/master/src/prevector.h#L396
6032019-05-06T21:40:31  <tryphe> sipa, luke-jr, but i zero out the memory in the destructor. that's what it's for...
6042019-05-06T21:41:55  <sipa> tryphe: the destructor is invoked automatically when destroying the object (when it goes out of scope, when delete is called, ...); you usually don't need to invoke it yourself
6052019-05-06T21:42:07  <luke-jr> sipa: hmm, I figured since new can be used with preallocated space, so could delete, but I guess not
6062019-05-06T21:42:24  <sipa> the only counterexample i know is when you're writing your own container classes that manually manage memory
6072019-05-06T21:43:57  *** EagleTM has quit IRC
6082019-05-06T21:44:12  <sipa> luke-jr: https://en.cppreference.com/w/cpp/language/new#Placement_new
6092019-05-06T21:45:07  <luke-jr> sipa: yes, that's what I mean
6102019-05-06T21:47:24  *** bitcoin-git has joined #bitcoin-core-dev
6112019-05-06T21:47:24  <bitcoin-git> [bitcoin] hebasto closed pull request #15966: net: Drop the ancient miniUPnPc API version support (master...20190506-drop-ancient-miniupnpc-api) https://github.com/bitcoin/bitcoin/pull/15966
6122019-05-06T21:47:37  *** bitcoin-git has left #bitcoin-core-dev
6132019-05-06T21:49:18  <tryphe> sipa, right, it's just hard to explain how i'm using it, it's a thread cleanup at the end of an application. if i invoke the destructor inside of itself, i don't have to call 'delete' from main() and the pointer gets popped off of the stack when main unwinds
6142019-05-06T21:49:56  <tryphe> sipa, i guess i wrote "this->Class()" because i have "delete" all over the place and wanted to mark "i'm exiting the thread here"
6152019-05-06T21:50:42  <tryphe> well, thread manager*
6162019-05-06T21:50:53  <sipa> ah, this is starting to get off topic :)
6172019-05-06T21:51:00  <tryphe> sipa, lol, sorry <3
6182019-05-06T21:54:44  *** waxwing has quit IRC
6192019-05-06T21:54:45  *** waxwing has joined #bitcoin-core-dev
6202019-05-06T21:57:10  *** shesek has quit IRC
6212019-05-06T21:58:02  *** hebasto has quit IRC
6222019-05-06T22:05:54  *** Yamato has joined #bitcoin-core-dev
6232019-05-06T22:06:18  *** Yamato is now known as Guest280
6242019-05-06T22:06:48  *** Guest280 has quit IRC
6252019-05-06T22:07:22  *** YamatoSueoka has joined #bitcoin-core-dev
6262019-05-06T22:08:38  *** YamatoSueoka_ has joined #bitcoin-core-dev
6272019-05-06T22:09:07  *** YamatoSueoka_ has quit IRC
6282019-05-06T22:09:32  *** YamatoSueoka_ has joined #bitcoin-core-dev
6292019-05-06T22:09:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6302019-05-06T22:10:06  *** YamatoSueoka_ has quit IRC
6312019-05-06T22:10:32  *** YamatoSueoka_ has joined #bitcoin-core-dev
6322019-05-06T22:11:59  *** YamatoSueoka has quit IRC
6332019-05-06T22:13:03  *** YamatoSueoka_ has quit IRC
6342019-05-06T22:37:42  *** spinza has quit IRC
6352019-05-06T23:03:30  *** shesek has joined #bitcoin-core-dev
6362019-05-06T23:11:06  *** spinza has joined #bitcoin-core-dev
6372019-05-06T23:14:06  *** drexl_ has quit IRC
6382019-05-06T23:15:51  *** promag has quit IRC
6392019-05-06T23:16:29  *** ccdle12 has joined #bitcoin-core-dev
6402019-05-06T23:17:59  *** jeremyrubin has joined #bitcoin-core-dev
6412019-05-06T23:18:51  *** dviola has joined #bitcoin-core-dev
6422019-05-06T23:19:06  <jeremyrubin> I happened to be reviewing VerifyScript, and wanted to check that it is the intended behavior that if CastToBool(witnessprogram) == false that validation fails?
6432019-05-06T23:20:02  <jeremyrubin> I just couldn't find it in the documentation (practically speaking it doesn't exclude very many scripts...)
6442019-05-06T23:20:29  <sipa> jeremyrubin: yes
6452019-05-06T23:20:47  <sipa> "not very many" is really "practically none", as the witness program is a hash
6462019-05-06T23:21:31  *** ccdle12 has quit IRC
6472019-05-06T23:22:05  *** scoop has joined #bitcoin-core-dev
6482019-05-06T23:23:03  <jeremyrubin> Yep it's fine, just wanted to clarify as it's not documented that it is intentional.
6492019-05-06T23:24:58  <jeremyrubin> The same sort of thing is true for P2SH
6502019-05-06T23:25:55  <jeremyrubin> My reason for looking at it is refactoring the VerifyScript code so that I understand it better.
6512019-05-06T23:32:16  *** ccdle12 has joined #bitcoin-core-dev
6522019-05-06T23:36:00  *** ccdle12 has quit IRC
6532019-05-06T23:36:07  *** ccdle12 has joined #bitcoin-core-dev
6542019-05-06T23:41:05  *** bitbee has quit IRC
6552019-05-06T23:42:16  *** bitbee has joined #bitcoin-core-dev
6562019-05-06T23:50:42  *** DeanGuss has joined #bitcoin-core-dev
6572019-05-06T23:56:20  *** DeanGuss has quit IRC
6582019-05-06T23:56:35  *** DeanGuss has joined #bitcoin-core-dev
6592019-05-06T23:58:27  *** sipa has quit IRC