< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d636f3943d39...b33ca14f594e
< bitcoin-git> bitcoin/master 95543d8 practicalswift: [net] Avoid possibility of NULL pointer dereference in MarkBlockAsInFlight(...)...
< bitcoin-git> bitcoin/master b33ca14 Pieter Wuille: Merge #9549: [net] Avoid possibility of NULL pointer dereference in MarkBlockAsInFlight(...)...
< bitcoin-git> [bitcoin] sipa closed pull request #9549: [net] Avoid possibility of NULL pointer dereference in MarkBlockAsInFlight(...) (master...avoid-potential-null-pointer-dereference-in-markblockasinflight) https://github.com/bitcoin/bitcoin/pull/9549
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b33ca14f594e...efbcf2b1d5ff
< bitcoin-git> bitcoin/master d9bec88 Pieter Wuille: Use REJECT_DUPLICATE for already known and conflicted txn
< bitcoin-git> bitcoin/master efbcf2b Pieter Wuille: Merge #10503: Use REJECT_DUPLICATE for already known and conflicted txn...
< bitcoin-git> [bitcoin] sipa closed pull request #10503: Use REJECT_DUPLICATE for already known and conflicted txn (master...more61duplicate) https://github.com/bitcoin/bitcoin/pull/10503
< bitcoin-git> [bitcoin] sipa pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/efbcf2b1d5ff...b3eb0d648551
< bitcoin-git> bitcoin/master ec1271f Matt Corallo: Remove useless mapNextTx lookup in CTxMemPool::TrimToSize....
< bitcoin-git> bitcoin/master 3533fb4 Matt Corallo: Return a bool in SpendCoin to restore pre-per-utxo assert semantics...
< bitcoin-git> bitcoin/master f58349c Matt Corallo: Restore some assert semantics in sigop cost calculations...
< bitcoin-git> [bitcoin] sipa closed pull request #10537: Few Minor per-utxo assert-semantics re-adds and tweak (master...2017-06-per-utxo-fixes) https://github.com/bitcoin/bitcoin/pull/10537
< bitcoin-git> [bitcoin] practicalswift opened pull request #10642: Use the _MSC_VER macro only if it is defined (master...undefined-msc-ver) https://github.com/bitcoin/bitcoin/pull/10642
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/b3eb0d648551...d083bd9b9c52
< bitcoin-git> bitcoin/master c53c983 Andrew Chow: Replace cookie auth in tests...
< bitcoin-git> bitcoin/master 3ec5ad8 Andrew Chow: Add test for rpcuser/rpcpassword
< bitcoin-git> bitcoin/master 279fde5 Andrew Chow: Check for rpcuser/rpcpassword first then for cookie...
< bitcoin-git> [bitcoin] laanwj closed pull request #10533: [tests] Use cookie auth instead of rpcuser and rpcpassword (master...tests-use-cookie-auth) https://github.com/bitcoin/bitcoin/pull/10533
< bitcoin-git> [bitcoin] rexuslexus opened pull request #10643: TestCoin 0.0.1 (master...master) https://github.com/bitcoin/bitcoin/pull/10643
< bitcoin-git> [bitcoin] rexuslexus closed pull request #10643: TestCoin 0.0.1 (master...master) https://github.com/bitcoin/bitcoin/pull/10643
< achow101> anyone know what's up with travis failing on #10637?
< gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
< jonasschnelli> achow101: unknown location(0): fatal error: in "coin_selection_tests/bnb_search_test": std::out_of_range: vector::_M_range_check
< jonasschnelli> mempool_limit.py | ✖ Failed | 4 s
< jonasschnelli> fundrawtransaction.py | ✖ Failed | 12 s
< sipa> sounds like an out of bounds access of a vector
< jonasschnelli> The rpc test failures are reported here: https://travis-ci.org/bitcoin/bitcoin/jobs/245174021
< achow101> jonasschnelli: there's also a build failure too
< jonasschnelli> unknown location(0): fatal error: in "coin_selection_tests/bnb_search_test": signal: SIGABRT (application abort requested)
< jonasschnelli> test_bitcoin: key.cpp:292: void ECC_Start(): Assertion `secp256k1_context_sign == __null' failed.
< jonasschnelli> haven't spotted the build error so far
< achow101> it's in one of the other travis builds
< gmaxwell> some of the builds run with instrumented STL that detect things like out of range accesses to vectors. (often accessing [0] in an empty vector.)
< jonasschnelli> achow101: I guess compiling on a Trusty 14.04 VM and valgrund/lldb|gdb could help
< jonasschnelli> *valgrind
< gmaxwell> you can skip the vm stuff and just run valgrind on your test, it'll likely turn it up.
< achow101> I'll try
< achow101> valgrind reported no problems
< jonasschnelli> achow101: OSX?
< achow101> no, on ubuntu 17.04
< achow101> I don't have a windows or osx machine readily available
< jonasschnelli> I had this before and IIRC I could also not reproduce some of the test failures... maybe VM Trusty 14.04
< jonasschnelli> achow101: maybe double check the travis build env (see what gmaxwell mentioned above "some of the builds run with instrumented STL")?
< jonasschnelli> The progress is fake..
< jonasschnelli> And it's a bit hackish... I hope someone has a better design for the callback
< jonasschnelli> I detected db corruption when building a UTXO db on regtest with 0.14.2 (generate 100) and then exit on ShutdownRequested() in CCoinsViewDB::Upgrade()
< jonasschnelli> * exit on master + the work above
< cfields> achow101: note that the last time this came up, it was an issue of: memcpy(foo, bar[0], 0), where bar was empty. Valgrind won't report it because the out-of-bounds memory isn't actually copied, but it's still a bad an idea to [0] an empty container.
< achow101> I'm pretty sure I don't have anything like that in my changes
< sipa> jonasschnelli: i recently fixed a bug that could cause that
< jonasschnelli> sipa: already merged? Then I guess I should retest
< sipa> jonasschnelli: a few days ago
< jonasschnelli> Not sure if the approach of a "c" keypress in splashscreen to abort the UTXO-set upgrade makes sense..
< jonasschnelli> Though adding buttons on splashscreen is – with the current design – cumbersome
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #10644: Slightly overhaul NSI pixmaps (master...2017/06/cleanup) https://github.com/bitcoin/bitcoin/pull/10644
< bitcoin-git> [bitcoin] practicalswift opened pull request #10645: Use nullptr instead of zero (0) as the null pointer constant (master...welcome-nullptr-goodbye-0) https://github.com/bitcoin/bitcoin/pull/10645
< achow101> it seems that the problem may be due to my use of long instead of CAmount in one of the tests I wrote
< sipa> jonasschnelli: what is the sleep for?
< jonasschnelli> sipa: dummy progress
< jonasschnelli> only to test
< sipa> oh
< jonasschnelli> jonasschnelli: you should add the right code and replace "progress += 0.00001;"
< jonasschnelli> Now I start to ping myself
< jonasschnelli> sipa: ... and remove the sleep
< sipa> you should not remove sleep from yourself
< sipa> or you'll end up doing things like pining yourself
< jonasschnelli> hahaa
< * jonasschnelli> feels like "progress += 0.00001;" in reallife
< sipa> jonasschnelli: uh... nvm
< sipa> the bug i was talking about is in the non-atomic upgrade PR
< sipa> not in master
< jonasschnelli> okay. Because I just tested with master and still have the corruption..
< sipa> :(
< jonasschnelli> reminds me that we should have a strategy of how to test upgrades (chainstate-db, old wallet files) in functional tests
< sipa> that's very hard, unless you store an old version's chainstate inside the test..
< sipa> just logistically
< jonasschnelli> I think that would be the simplest solution.
< jonasschnelli> Compiling an old version will not be possible (at lest not in travis CI)
< sdaftuar> yeah its hard to get to work in travis, but not so hard conceptually to write the test in our test framework. passing in a custom binary to a functional test works fine.
< jonasschnelli> I think having some test old blobs fixtures may be okay
< sdaftuar> i believe i wrote a test like this in p2p-segwit (before we supported modifying bip9 parameters on the command line)
< jonasschnelli> It's one of the most lacking things in our test framework (migrations)
< sipa> those blobs could even be dependencies (as in, for the depends framework)
< sipa> with known hashes, but downloaded at build time
< jonasschnelli> yes.. sure.
< jonasschnelli> Especially if they are large...
< jonasschnelli> for wallet files, I don't mind having a couple of 20kb bdb 4.8 files in our test framework