< 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/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
< 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>
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] 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