-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: Tsan times out on travis, move to cirrus #12
Labels
good first issue
Good for newcomers
Comments
The pull should be opened against the main repo, of course, not the gui repo |
See also #5 (comment) by @hebasto |
laanwj
added a commit
that referenced
this issue
Oct 29, 2020
fa56d56 fuzz: Properly initialize PrecomputedTransactionData (MarcoFalke) Pull request description: Fixes: ``` script_flags: script/interpreter.cpp:1512: bool SignatureHashSchnorr(uint256 &, const ScriptExecutionData &, const T &, uint32_t, uint8_t, SigVersion, const PrecomputedTransactionData &) [T = CTransaction]: Assertion `cache.m_bip341_taproot_ready && cache.m_spent_outputs_ready' failed. ==34989== ERROR: libFuzzer: deadly signal #0 0x55e90077ff11 in __sanitizer_print_stack_trace (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x20cf11) #1 0x55e9006cb068 in fuzzer::PrintStackTrace() (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x158068) #2 0x55e9006b01b3 in fuzzer::Fuzzer::CrashCallback() (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x13d1b3) #3 0x7f6fb89383bf (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf) #4 0x7f6fb855018a in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618a) #5 0x7f6fb852f858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x25858) #6 0x7f6fb852f728 (/lib/x86_64-linux-gnu/libc.so.6+0x25728) #7 0x7f6fb8540f35 in __assert_fail (/lib/x86_64-linux-gnu/libc.so.6+0x36f35) #8 0x55e9008275bd in bool SignatureHashSchnorr<CTransaction>(uint256&, ScriptExecutionData const&, CTransaction const&, unsigned int, unsigned char, SigVersion, PrecomputedTransactionData const&) /tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/script/interpreter.cpp:1512:5 #9 0x55e900825a3f in GenericTransactionSignatureChecker<CTransaction>::CheckSchnorrSignature(Span<unsigned char const>, Span<unsigned char const>, SigVersion, ScriptExecutionData const&, ScriptError_t*) const /tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/script/interpreter.cpp:1699:10 #10 0x55e900832503 in VerifyWitnessProgram(CScriptWitness const&, int, std::vector<unsigned char, std::allocator<unsigned char> > const&, unsigned int, BaseSignatureChecker const&, ScriptError_t*, bool) /tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/script/interpreter.cpp:1900:26 #11 0x55e90082ecb5 in VerifyScript(CScript const&, CScript const&, CScriptWitness const*, unsigned int, BaseSignatureChecker const&, ScriptError_t*) /tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/script/interpreter.cpp:1977:18 #12 0x55e9007a9b61 in test_one_input(std::vector<unsigned char, std::allocator<unsigned char> > const&) /tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags.cpp:51:30 #13 0x55e9007d0b49 in LLVMFuzzerTestOneInput /tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/fuzz.cpp:36:5 #14 0x55e9006b1871 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x13e871) #15 0x55e9006b0fb5 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x13dfb5) #16 0x55e9006b38d7 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x1408d7) #17 0x55e9006b3c39 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x140c39) #18 0x55e9006a290e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x12f90e) #19 0x55e9006cb752 in main (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x158752) #20 0x7f6fb85310b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #21 0x55e9006776ad in _start (/tmp/bitcoin-core/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/fuzz/script_flags+0x1046ad) ACKs for top commit: laanwj: Code review ACK fa56d56 Tree-SHA512: 5637b0a0d982360df32d8cd39e913395967af02ec746508fc5f2fd649695c58bfaaf18ef76f4ca9da764d34fdd63dfe188317dd41b2ed57534bd4055a05ae870
maflcko
pushed a commit
that referenced
this issue
Apr 28, 2021
fa1fdeb fuzz: Ensure prevout is consensus-valid (MarcoFalke) Pull request description: It shouldn't be possible to create consensus-invalid prevouts, so there is no need to fuzz them. To reproduce: ``` $ echo 'AAAAAAEAAAAAAQF0Rw0SGsrit4+YZSEfpcQT/o+bJbjgVjATUHqrCfRE+QsBAAAXFgAUlsvXHgGV ZxF3QXxitwe1tIOYdLj2NePHATl9CgAAAAAAGXapFOFHg1yqRFl7soeowwpIEOoe9G1NiKwCRzBE AiAx6F2Q008gvJnok6JiyOn7lPqCJJmDiI2omRNXT1Q7XAIgCQP6WJizAqhnvImpQqYMJkqePGvx Jy/pGRMy1iNL0ecDIQJr4tWomVTBfjpyMFMOD9aDAR5gkByOIYiaQOv8P/sRztP3pS8RDAAAEUUE NQBwYAAAAAC5F6kUTLIzj/lKP2Hmpwyzukns2eweRkOH' | base64 --decode > /tmp/a $ FUZZ=script_flags ./src/test/fuzz/fuzz /tmp/a INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 59714236 INFO: Loaded 1 modules (212532 inline 8-bit counters): 212532 [0x55987fb3f668, 0x55987fb7349c), INFO: Loaded 1 PC tables (212532 PCs): 212532 [0x55987fb734a0,0x55987feb17e0), ./src/test/fuzz/fuzz: Running 1 inputs 1 time(s) each. Running: /tmp/a fuzz: script/interpreter.cpp:1495: bool HandleMissingData(MissingDataBehavior): Assertion `!"Missing data"' failed. ==520092== ERROR: libFuzzer: deadly signal #0 0x55987f111180 in __sanitizer_print_stack_trace (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x5ea180) #1 0x55987f0ba828 in fuzzer::PrintStackTrace() fuzzer.o #2 0x55987f09de43 in fuzzer::Fuzzer::CrashCallback() fuzzer.o #3 0x7fd003d563bf (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf) #4 0x7fd00399a18a in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618a) #5 0x7fd003979858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x25858) #6 0x7fd003979728 (/lib/x86_64-linux-gnu/libc.so.6+0x25728) #7 0x7fd00398af35 in __assert_fail (/lib/x86_64-linux-gnu/libc.so.6+0x36f35) #8 0x55987f8ce194 in HandleMissingData(MissingDataBehavior) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1495:9 #9 0x55987f8ce194 in GenericTransactionSignatureChecker<CTransaction>::CheckECDSASignature(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, CScript const&, SigVersion) const /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1685:68 #10 0x55987f8cbbc8 in EvalChecksigPreTapscript(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, prevector<28u, unsigned char, unsigned int, int>::const_iterator, prevector<28u, unsigned char, unsigned int, int>::const_iterator, unsigned int, BaseSignatureChecker const&, SigVersion, ScriptError_t*, bool&) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:363:24 #11 0x55987f8cbbc8 in EvalChecksig(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, prevector<28u, unsigned char, unsigned int, int>::const_iterator, prevector<28u, unsigned char, unsigned int, int>::const_iterator, ScriptExecutionData&, unsigned int, BaseSignatureChecker const&, SigVersion, ScriptError_t*, bool&) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:421:16 #12 0x55987f8c5a01 in EvalScript(std::vector<std::vector<unsigned char, std::allocator<unsigned char> >, std::allocator<std::vector<unsigned char, std::allocator<unsigned char> > > >&, CScript const&, unsigned int, BaseSignatureChecker const&, SigVersion, ScriptExecutionData&, ScriptError_t*) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1094:26 #13 0x55987f8d6d6e in ExecuteWitnessScript(Span<std::vector<unsigned char, std::allocator<unsigned char> > const> const&, CScript const&, unsigned int, SigVersion, BaseSignatureChecker const&, ScriptExecutionData&, ScriptError_t*) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1843:10 #14 0x55987f8d48fc in VerifyWitnessProgram(CScriptWitness const&, int, std::vector<unsigned char, std::allocator<unsigned char> > const&, unsigned int, BaseSignatureChecker const&, ScriptError_t*, bool) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1904:20 #15 0x55987f8d3d8b in VerifyScript(CScript const&, CScript const&, CScriptWitness const*, unsigned int, BaseSignatureChecker const&, ScriptError_t*) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:2045:22 #16 0x55987f201d47 in script_flags_fuzz_target(Span<unsigned char const>) /root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/script_flags.cpp:54:30 #17 0x55987f11447f in std::_Function_handler<void (Span<unsigned char const>), void (*)(Span<unsigned char const>)>::_M_invoke(std::_Any_data const&, Span<unsigned char const>&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:300:2 #18 0x55987f8aed17 in std::function<void (Span<unsigned char const>)>::operator()(Span<unsigned char const>) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14 #19 0x55987f8aed17 in LLVMFuzzerTestOneInput /root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz.cpp:63:5 #20 0x55987f09f5e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) fuzzer.o #21 0x55987f0894e2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) fuzzer.o #22 0x55987f08f2da in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) fuzzer.o #23 0x55987f0bb002 in main (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x594002) #24 0x7fd00397b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #25 0x55987f06420d in _start (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x53d20d) NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ACKs for top commit: practicalswift: Tested ACK fa1fdeb Tree-SHA512: 6130ed9ab6d8eeab901f64a1c069300e67d0b6009c42763262fe6edeab8192e088c1a3c1f61aee900b9ebbc48fbf6e837b41704bad592ec526398355766e208a
fanquake
pushed a commit
that referenced
this issue
Apr 29, 2021
Otherwise it is not possible to run bench_bitcoin with clang-12 + ASAN compiled. Output: $ src/bench/bench_bitcoin bench/nanobench.h:1107:15: runtime error: left shift of 4982565676696827473 by 27 places cannot be represented in type 'uint64_t' (aka 'unsigned long') #0 0x5623d6a13137 in ankerl::nanobench::Rng::rotl(unsigned long, unsigned int) /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/./bench/nanobench.h:1107:15 #1 0x5623d6a13137 in ankerl::nanobench::Rng::operator()() /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/./bench/nanobench.h:1075:10 #2 0x5623d6a05c5b in ankerl::nanobench::Rng::Rng(unsigned long) /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/./bench/nanobench.h:3135:9 #3 0x5623d6a0ca51 in ankerl::nanobench::detail::IterationLogic::Impl::Impl(ankerl::nanobench::Bench const&) /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/./bench/nanobench.h:2206:13 #4 0x5623d69f8f73 in ankerl::nanobench::detail::IterationLogic::IterationLogic(ankerl::nanobench::Bench const&) /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/./bench/nanobench.h:2215:18 #5 0x5623d690f165 in ankerl::nanobench::Bench& ankerl::nanobench::Bench::run<AddrManAdd(ankerl::nanobench::Bench&)::$_0>(AddrManAdd(ankerl::nanobench::Bench&)::$_0&&) /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/./bench/nanobench.h:1114:28 #6 0x5623d690e26e in AddrManAdd(ankerl::nanobench::Bench&) /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/bench/addrman.cpp:76:11 #7 0x5623d69279d6 in void std::__invoke_impl<void, void (*&)(ankerl::nanobench::Bench&), ankerl::nanobench::Bench&>(std::__invoke_other, void (*&)(ankerl::nanobench::Bench&), ankerl::nanobench::Bench&) /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/invoke.h:60:14 #8 0x5623d6927921 in std::enable_if<is_invocable_r_v<void, void (*&)(ankerl::nanobench::Bench&), ankerl::nanobench::Bench&>, void>::type std::__invoke_r<void, void (*&)(ankerl::nanobench::Bench&), ankerl::nanobench::Bench&>(void (*&)(ankerl::nanobench::Bench&), ankerl::nanobench::Bench&) /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/invoke.h:110:2 #9 0x5623d692775f in std::_Function_handler<void (ankerl::nanobench::Bench&), void (*)(ankerl::nanobench::Bench&)>::_M_invoke(std::_Any_data const&, ankerl::nanobench::Bench&) /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/std_function.h:291:9 #10 0x5623d692dbd5 in std::function<void (ankerl::nanobench::Bench&)>::operator()(ankerl::nanobench::Bench&) const /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/std_function.h:622:14 #11 0x5623d692cd44 in benchmark::BenchRunner::RunAll(benchmark::Args const&) /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/bench/bench.cpp:65:13 #12 0x5623d69282bf in main /bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/bench/bench_bitcoin.cpp:63:5 #13 0x7f6812010564 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28564) #14 0x5623d685f4dd in _start (/bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/bench/bench_bitcoin+0x13754dd) SUMMARY: UndefinedBehaviorSanitizer: invalid-shift-base bench/nanobench.h:1107:15 in $ clang --version Ubuntu clang version 12.0.0-1ubuntu1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin
maflcko
pushed a commit
that referenced
this issue
May 7, 2021
…e a dereferenceable iterator outside its valid range) fa09871 refactor: Avoid sign-compare compiler warning in util/asmap (MarcoFalke) Pull request description: Can be reproduced on current master with `D_GLIBCXX_DEBUG`: ``` /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/debug/safe_iterator.h:883: In function: __gnu_debug::_Safe_iterator<type-parameter-0-0, type-parameter-0-1, std::random_access_iterator_tag>::_Self __gnu_debug::operator+(const __gnu_debug::_Safe_iterator<type-parameter-0-0, type-parameter-0-1, std::random_access_iterator_tag>::_Self &, __gnu_debug::_Safe_iterator<type-parameter-0-0, type-parameter-0-1, std::random_access_iterator_tag>::difference_type) Error: attempt to advance a dereferenceable iterator 369 steps, which falls outside its valid range. Objects involved in the operation: iterator @ 0x0x7ffd3d613138 { type = std::__cxx1998::_Bit_const_iterator (constant iterator); state = dereferenceable; references sequence with type 'std::__debug::vector<bool, std::allocator<bool> >' @ 0x0x7ffd3d663590 } ==65050== ERROR: libFuzzer: deadly signal #0 0x559ab9787690 in __sanitizer_print_stack_trace (/bitcoin/src/test/fuzz/fuzz+0x5a1690) #1 0x559ab9733998 in fuzzer::PrintStackTrace() (/bitcoin/src/test/fuzz/fuzz+0x54d998) #2 0x559ab9718ae3 in fuzzer::Fuzzer::CrashCallback() (/bitcoin/src/test/fuzz/fuzz+0x532ae3) #3 0x7f70a0e723bf (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf) #4 0x7f70a0b3418a in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618a) #5 0x7f70a0b13858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x25858) #6 0x7f70a0f21148 (/lib/x86_64-linux-gnu/libstdc++.so.6+0xa1148) #7 0x559ab9f60a96 in __gnu_debug::operator+(__gnu_debug::_Safe_iterator<std::__cxx1998::_Bit_const_iterator, std::__debug::vector<bool, std::allocator<bool> >, std::random_access_iterator_tag> const&, long) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/debug/safe_iterator.h:881:2 #8 0x559ab9f61062 in SanityCheckASMap(std::__debug::vector<bool, std::allocator<bool> > const&, int) util/asmap.cpp:159:21 #9 0x559ab9e4fdfa in SanityCheckASMap(std::__debug::vector<bool, std::allocator<bool> > const&) netaddress.cpp:1242:12 #10 0x559ab9793fcb in addrman_fuzz_target(Span<unsigned char const>) test/fuzz/addrman.cpp:43:14 #11 0x559ab978a03c in std::_Function_handler<void (Span<unsigned char const>), void (*)(Span<unsigned char const>)>::_M_invoke(std::_Any_data const&, Span<unsigned char const>&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:300:2 #12 0x559aba2692c7 in std::function<void (Span<unsigned char const>)>::operator()(Span<unsigned char const>) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14 #13 0x559aba269132 in LLVMFuzzerTestOneInput test/fuzz/fuzz.cpp:63:5 #14 0x559ab971a1a1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/bitcoin/src/test/fuzz/fuzz+0x5341a1) #15 0x559ab97198e5 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/bitcoin/src/test/fuzz/fuzz+0x5338e5) #16 0x559ab971bb87 in fuzzer::Fuzzer::MutateAndTestOne() (/bitcoin/src/test/fuzz/fuzz+0x535b87) #17 0x559ab971c885 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/bitcoin/src/test/fuzz/fuzz+0x536885) #18 0x559ab970b23e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/bitcoin/src/test/fuzz/fuzz+0x52523e) #19 0x559ab9734082 in main (/bitcoin/src/test/fuzz/fuzz+0x54e082) #20 0x7f70a0b150b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #21 0x559ab96dffdd in _start (/bitcoin/src/test/fuzz/fuzz+0x4f9fdd) ACKs for top commit: sipa: utACK fa09871 vasild: ACK fa09871 Tree-SHA512: 802fda33bda40fe2521f1e3be075ceddc5fd9ba185bd494286e50019931dfd688da7a6513601138b1dc7bb8e80ae47c8572902406eb59f68990619ddb2656748
maflcko
pushed a commit
that referenced
this issue
May 15, 2021
…st RPC fa2e614 test: Fix off-by-one in mockscheduler test RPC (MarcoFalke) Pull request description: Fixes: ``` fuzz: scheduler.cpp:83: void CScheduler::MockForward(std::chrono::seconds): Assertion `delta_seconds.count() > 0 && delta_seconds < std::chrono::hours{1}' failed. ==1059066== ERROR: libFuzzer: deadly signal #0 0x558f75449c10 in __sanitizer_print_stack_trace (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x5fec10) #1 0x558f753f32b8 in fuzzer::PrintStackTrace() fuzzer.o #2 0x558f753d68d3 in fuzzer::Fuzzer::CrashCallback() fuzzer.o #3 0x7f4a3cbbb3bf (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf) #4 0x7f4a3c7ff18a in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618a) #5 0x7f4a3c7de858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x25858) #6 0x7f4a3c7de728 (/lib/x86_64-linux-gnu/libc.so.6+0x25728) #7 0x7f4a3c7eff35 in __assert_fail (/lib/x86_64-linux-gnu/libc.so.6+0x36f35) #8 0x558f7588a913 in CScheduler::MockForward(std::chrono::duration<long, std::ratio<1l, 1l> >) scheduler.cpp:83:5 #9 0x558f75b0e5b1 in mockscheduler()::$_7::operator()(RPCHelpMan const&, JSONRPCRequest const&) const rpc/misc.cpp:435:30 #10 0x558f75b0e5b1 in std::_Function_handler<UniValue (RPCHelpMan const&, JSONRPCRequest const&), mockscheduler()::$_7>::_M_invoke(std::_Any_data const&, RPCHelpMan const&, JSONRPCRequest const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:285:9 #11 0x558f7587a141 in std::function<UniValue (RPCHelpMan const&, JSONRPCRequest const&)>::operator()(RPCHelpMan const&, JSONRPCRequest const&) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14 #12 0x558f7587a141 in RPCHelpMan::HandleRequest(JSONRPCRequest const&) const rpc/util.cpp:565:26 #13 0x558f756c0086 in CRPCCommand::CRPCCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, RPCHelpMan (*)())::'lambda'(JSONRPCRequest const&, UniValue&, bool)::operator()(JSONRPCRequest const&, UniValue&, bool) const ./rpc/server.h:110:91 #14 0x558f756c0086 in std::_Function_handler<bool (JSONRPCRequest const&, UniValue&, bool), CRPCCommand::CRPCCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, RPCHelpMan (*)())::'lambda'(JSONRPCRequest const&, UniValue&, bool)>::_M_invoke(std::_Any_data const&, JSONRPCRequest const&, UniValue&, bool&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:285:9 #15 0x558f756b8592 in std::function<bool (JSONRPCRequest const&, UniValue&, bool)>::operator()(JSONRPCRequest const&, UniValue&, bool) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14 #16 0x558f756b8592 in ExecuteCommand(CRPCCommand const&, JSONRPCRequest const&, UniValue&, bool) rpc/server.cpp:480:20 #17 0x558f756b8592 in ExecuteCommands(std::vector<CRPCCommand const*, std::allocator<CRPCCommand const*> > const&, JSONRPCRequest const&, UniValue&) rpc/server.cpp:444:13 #18 0x558f756b8017 in CRPCTable::execute(JSONRPCRequest const&) const rpc/server.cpp:464:13 #19 0x558f7552457a in (anonymous namespace)::RPCFuzzTestingSetup::CallRPC(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) test/fuzz/rpc.cpp:50:25 #20 0x558f7552457a in rpc_fuzz_target(Span<unsigned char const>) test/fuzz/rpc.cpp:354:28 #21 0x558f7544cf0f in std::_Function_handler<void (Span<unsigned char const>), void (*)(Span<unsigned char const>)>::_M_invoke(std::_Any_data const&, Span<unsigned char const>&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:300:2 #22 0x558f75c05197 in std::function<void (Span<unsigned char const>)>::operator()(Span<unsigned char const>) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14 #23 0x558f75c05197 in LLVMFuzzerTestOneInput test/fuzz/fuzz.cpp:74:5 #24 0x558f753d8073 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) fuzzer.o #25 0x558f753c1f72 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) fuzzer.o #26 0x558f753c7d6a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) fuzzer.o #27 0x558f753f3a92 in main (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x5a8a92) #28 0x7f4a3c7e00b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #29 0x558f7539cc9d in _start (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x551c9d) ACKs for top commit: practicalswift: cr ACK fa2e614 Tree-SHA512: cfa120265261f0ad019b46c426b915c1c007806b37aecb27016ce780a0ddea5e6fc9b09065fd40684b11183dcd3bf543558d7a655e604695021653540266baf7
knst
pushed a commit
to knst/dash
that referenced
this issue
Jan 13, 2024
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from bitcoin#19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
knst
pushed a commit
to knst/dash
that referenced
this issue
Jan 15, 2024
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from bitcoin#19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
knst
pushed a commit
to knst/dash
that referenced
this issue
Jan 17, 2024
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from bitcoin#19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
knst
pushed a commit
to knst/dash
that referenced
this issue
Jan 19, 2024
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from bitcoin#19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
knst
pushed a commit
to knst/dash
that referenced
this issue
Jan 20, 2024
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from bitcoin#19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
knst
pushed a commit
to knst/dash
that referenced
this issue
Jan 24, 2024
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from bitcoin#19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
knst
pushed a commit
to knst/dash
that referenced
this issue
Jan 29, 2024
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from bitcoin#19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
PastaPastaPasta
pushed a commit
to knst/dash
that referenced
this issue
Feb 1, 2024
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from bitcoin#19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Similar to bitcoin/bitcoin#19321
Useful skills:
Git, Bash
Want to work on this issue?
For guidance on contributing, please read CONTRIBUTING.md before opening your pull request.
The text was updated successfully, but these errors were encountered: