💬 theStack commented on pull request "test: add ripemd160 to test framework modules list":
(https://github.com/bitcoin/bitcoin/pull/27542#discussion_r1182465178)
Good idea, done.

📝 sipa opened a pull request: "Add support for "partial" fuzzers that indicate usefulness"
(https://github.com/bitcoin/bitcoin/pull/27552)
This adds supports for fuzz targets that return a boolean: `true` is the normal case, while `false` indicates the input was uninteresting and should not under any circumstances be added to the corpus. This is intended for fuzz targets that have some early bail-out criteria, so that the fuzzer doesn't continue to iterate on them.

💬 MarcoFalke commented on pull request "test: add ripemd160 to test framework modules list":
(https://github.com/bitcoin/bitcoin/pull/27542#issuecomment-1531367642)
lgtm ACK 82e6e3cae50d30b28b98f0cb7789c28e68170d5e

💬 fanquake commented on pull request "ci: use LLVM/clang-16 in native_asan job":
(https://github.com/bitcoin/bitcoin/pull/27360#discussion_r1182469334)
Applied, and we're no-longer seeing disk issues.

💬 dergoegge commented on pull request "ci: use LLVM/clang-16 in native_asan job":
(https://github.com/bitcoin/bitcoin/pull/27360#issuecomment-1531376873)
utACK f952e679cd9c642e2c1f484ad8d75510ce25324c

📝 MarcoFalke opened a pull request: "test: Simplify feature_fastprune.py"
(https://github.com/bitcoin/bitcoin/pull/27553)
The goal of the test is a single regression check to see if a RPC times out. It shouldn't do more than calling the RPC (and the minimum work needed to get there).

Fix that by removing all blocktools imports and a `for` loop.

💬 MarcoFalke commented on pull request "blockstorage: Adjust fastprune limit if block exceeds blockfile size":
(https://github.com/bitcoin/bitcoin/pull/27191#discussion_r1182471346)
Any reason to make this simple test more complicated than it needs to be? See https://github.com/bitcoin/bitcoin/pull/27553

💬 fanquake commented on issue "Build broken when enabling fuzzing on Apple M1 hw using homebrew llvm.":
(https://github.com/bitcoin/bitcoin/issues/27550#issuecomment-1531382862)
> not sure what is ar-lib, how can I install it? I googled but not much help

This is definitely a local issue. Make sure your tree is entirely clean. Could try a `git clean -fxd`, and then `./autogen.sh, ./configure ... ` etc.

💬 MarcoFalke commented on pull request "Add support for "partial" fuzzers that indicate usefulness":
(https://github.com/bitcoin/bitcoin/pull/27552#issuecomment-1531391032)
Can you add some context to explain how this interacts with fuzzing engines? Will this make it harder for engines to start from an empty input set? Often, to find a sufficiently long input to pass basic deserialization, fuzz engines will have to be guided, for example `-use_value_profile=1` for libfuzzer, and discarding the inputs on the way would mean they will never succeed passing basic deserialization?


Moreover, it could help to state a goal. Is it to keep the qa-assets repo small?

🚀 fanquake merged a pull request: "test: add ripemd160 to test framework modules list"
(https://github.com/bitcoin/bitcoin/pull/27542)

💬 kouloumos commented on pull request "tracing: macOS USDT support":
(https://github.com/bitcoin/bitcoin/pull/25541#issuecomment-1531396388)
> What's the status of this?

It seems that there isn't enough interest for this change. But anyway. with the current status of #26593, it doesn't make sense for this PR to be dealt with before that one is merged. Additionally, there is a chance that #26593 will make it easier to reason for macOS USDT support if [what I proposed ](https://github.com/bitcoin/bitcoin/pull/26593#pullrequestreview-1376804705)gets into the final PR.
Therefore, marking it as draft for now.

📝 kouloumos converted_to_draft a pull request: "tracing: macOS USDT support"
(https://github.com/bitcoin/bitcoin/pull/25541)
This PR adds macOS support for User-Space, Statically Defined Tracing (USDT) as well as dtrace example scripts based on the existing bpftrace scripts for Linux. This is tested on macOS 10.15.

## Overview

The current implementation of USDT only supports Linux as the `DTRACE_PROBE*(context, event, ...args)` macros are not supported on macOS. As initially referenced in https://github.com/bitcoin/bitcoin/pull/22238, the process of using USDT probes on macOS is slightly different and it's des
...

💬 MarcoFalke commented on pull request "ci: use LLVM/clang-16 in native_asan job":
(https://github.com/bitcoin/bitcoin/pull/27360#issuecomment-1531401667)
lgtm ACK f952e679cd9c642e2c1f484ad8d75510ce25324c

💬 dergoegge commented on pull request "Add support for "partial" fuzzers that indicate usefulness":
(https://github.com/bitcoin/bitcoin/pull/27552#discussion_r1182489285)
Just noting that this was only recently added to libFuzzer: https://reviews.llvm.org/D128749?id=441094

I think that is fine, running with older versions of libFuzzer makes little sense anyway.

🤔 dergoegge reviewed a pull request: "Add support for "partial" fuzzers that indicate usefulness"
(https://github.com/bitcoin/bitcoin/pull/27552#pullrequestreview-1409007192)
Concept ACK

💬 dergoegge commented on pull request "Add support for "partial" fuzzers that indicate usefulness":
(https://github.com/bitcoin/bitcoin/pull/27552#discussion_r1182486207)
Maybe worth noting that this will only work for libFuzzer? (or i guess any engine that uses the libFuzzer harness and respects the -1 return value)

💬 sipa commented on pull request "Add support for "partial" fuzzers that indicate usefulness":
(https://github.com/bitcoin/bitcoin/pull/27552#issuecomment-1531411293)
@MarcoFalke Fair question. I think the primary advantage is that it should help with the speed of fuzzing, by avoiding spending time on less interesting things. It is however somewhat delicate as you point out - if you mark too many things as "uninteresting", I can imagine it actually becomes harder to find a mutation path from one interesting test case to another.

🚀 fanquake merged a pull request: "test: added coverage to rpc_scantxoutset.py"
(https://github.com/bitcoin/bitcoin/pull/27453)

💬 sipa commented on pull request "Add support for "partial" fuzzers that indicate usefulness":
(https://github.com/bitcoin/bitcoin/pull/27552#discussion_r1182499692)
I see it a bit more abstract: the macro is for *writing* a test that has such a return value. Whether the fuzz infrastructure uses it in an independent question (and if there are ones using `LLVMFuzzerTestOneInput` that don't support the return value -1 at all, we should make sure it also isn't returned, even if `FUZZ_PARTIAL_TARGET` is used).

💬 MarcoFalke commented on pull request "Add support for "partial" fuzzers that indicate usefulness":
(https://github.com/bitcoin/bitcoin/pull/27552#issuecomment-1531421409)
Yeah, it may help or hurt, depending on your goal and the fuzz target. My recommendation would be to make this off by default, and add an option to enable it at run time. This certainly can't hurt and may help for the use cases that want to enable it.