Skip to content

Conversation

sipa
Copy link
Owner

@sipa sipa commented Dec 20, 2021

No description provided.

Copy link
Contributor

@darosior darosior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat. Code review ACK e2e18ee. I'm now going to further test this and will report.

Copy link
Contributor

@darosior darosior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A compilation failures i didn't catch before trying to test it with Bitcoin Core.

@sipa sipa force-pushed the 202112_norecurse branch 2 times, most recently from 4e47f27 to de22eb1 Compare December 20, 2021 22:59
Copy link
Contributor

@darosior darosior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple more comments after checking with my unit tests.

Copy link
Contributor

@darosior darosior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another compilation failure that for some reason i didn't encounter before.

// Invoke upfn with the last node.subs.size() elements of results as input.
assert(results.size() >= node.subs.size());
std::optional<Result> result{upfn(std::move(stack.back().state), node,
Span{results}.last(node.subs.size()))};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Span{results}.last(node.subs.size()))};
Span<Result>{results}.last(node.subs.size()))};

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That really shouldn't be necessary. Do you have an old span.h by any chance, or not using -std=c++17?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interestingly this only happened when building with fuzz enabled. I'll retry both builds from scratch and report.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So i still have this error (only) when building the fuzz target.

$ make V=1
Making all in src
make[1]: Entering directory '/home/darosior/projects/bitcoin/src'
make[2]: Entering directory '/home/darosior/projects/bitcoin/src'
make[3]: Entering directory '/home/darosior/projects/bitcoin'
make[3]: Leaving directory '/home/darosior/projects/bitcoin'
clang++ -std=c++17 -DHAVE_CONFIG_H -I. -I../src/config  -DABORT_ON_FAILED_ASSUME -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -I. -I./minisketch/include -I./secp256k1/include -I./univalue/include -I/home/darosior/projects/bitcoin/../db4/include -I/usr/include -I./leveldb/include -I./leveldb/helpers/memenv -DHAVE_BUILD_INFO  -Wstack-protector -fstack-protector-all -fcf-protection=full -fstack-clash-protection -Wall -Wextra -Wgnu -Wformat -Wformat-security -Wvla -Wshadow-field -Wthread-safety -Wrange-loop-analysis -Wredundant-decls -Wunused-member-function -Wdate-time -Wconditional-uninitialized -Woverloaded-virtual -Wsuggest-override -Wunreachable-code-loop-increment -Wimplicit-fallthrough -Wno-unused-parameter -Wno-self-assign -Wno-deprecated-copy   -fsanitize=fuzzer  -fPIE -g -O2 -MT test/fuzz/fuzz-miniscript_decode.o -MD -MP -MF test/fuzz/.deps/fuzz-miniscript_decode.Tpo -c -o test/fuzz/fuzz-miniscript_decode.o `test -f 'test/fuzz/miniscript_decode.cpp' || echo './'`test/fuzz/miniscript_decode.cpp
In file included from test/fuzz/miniscript_decode.cpp:8:
./script/miniscript.h:425:30: error: member reference base type 'Span' is not a structure or union
                Span{results}.last(node.subs.size()))};
                ~~~~~~~~~~~~~^~~~~
1 error generated.
make[2]: *** [Makefile:15058: test/fuzz/fuzz-miniscript_decode.o] Error 1
make[2]: Leaving directory '/home/darosior/projects/bitcoin/src'
make[1]: *** [Makefile:17529: all-recursive] Error 1
make[1]: Leaving directory '/home/darosior/projects/bitcoin/src'
make: *** [Makefile:823: all-recursive] Error 1
$ clang++ --version
Debian clang version 11.0.1-2

Copy link
Owner Author

@sipa sipa Dec 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@darosior Do you have a branch with everything integrated (bitcoin core, miniscript with this PR and fuzz test) that I can play around with?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you go: https://github.com/darosior/bitcoin/tree/miniscript_pr_83. Based on the watchonly PR (darosior/bitcoin#5).

I just re-tried on this branch tip and i can build without issue with:

./autogen.sh
./configure --enable-debug --enable-c++17 --without-gui --disable-bench "$@" BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include"
make -j20

But not with

./autogen.sh
./configure --enable-fuzz --enable-c++17 --with-sanitizers=fuzzer BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include" CC=clang CXX=clang++
make -j20

And the g++ used to build without the fuzz target:

g++ (Debian 10.3.0-11) 10.3.0

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very strange. I can build the fuzz tests without problem in your branch (clang++ --version => 12.0.0-3ubuntu1~21.04.2). I'll add the Span<Result> if that helps, but I'd still like to understand what causes this.

Copy link
Contributor

@darosior darosior Dec 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying with another clang version now.
EDIT: same error with clang++-9.
EDIT 2: so this is fixed starting with clang++-12. To be precise i used clang+llvm-12.0.1-x86_64-linux-gnu-ubuntu-16.04.tar.xz from https://github.com/llvm/llvm-project/releases/tag/llvmorg-12.0.1.

darosior added a commit to darosior/bitcoin that referenced this pull request Dec 22, 2021
Copy link
Contributor

@darosior darosior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK b2605c6 -- in addition to the previous code review and testing, for the past few days i've been fuzzing this both with the target from #83 and Bitcoin Core's descriptor_parse with darosior/bitcoin#5 applied. I have not encountered any failure to roundtrip nor any crash in ToString()/ToString().

@sipa sipa merged commit 5cb32a6 into master Dec 23, 2021
Copy link
Contributor

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Post merge code review ACK

case NodeType::WRAP_S: return (CScript() << OP_SWAP) + std::move(subs[0]);
case NodeType::WRAP_C: return std::move(subs[0]) + CScript() << (verify ? OP_CHECKSIGVERIFY : OP_CHECKSIG);
case NodeType::WRAP_D: return (CScript() << OP_DUP << OP_IF) + std::move(subs[0]) + (CScript() << OP_ENDIF);
case NodeType::WRAP_V: return std::move(subs[0]) + (node.subs[0]->GetType() << "x"_mst ? (CScript() << OP_VERIFY) : CScript());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another way to do this. Directly change the opcode to verify version in case the type is not "x"

  • OP_EQUAL -> OP_EQUALVERIFY
  • OP_CHECKSIG -> OP_CHECKSIGVERIFY
  • OP_CHECKMULTISIG -> OP_CHECKMULTISIGVERIFY

This avoids keeping track of the state variable verify. Just a note, no need to modify the existing implementation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'd still need verify for WRAP_S and AND_V though?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants