💬 MarcoFalke commented on pull request "test: added coverage to rpc_scantxoutset.py":
(https://github.com/bitcoin/bitcoin/pull/27453#issuecomment-1531333931)
lgtm ACK 24d55fb9cfab88f546df35be5c0069b9b645438c

💬 liuyangc3 commented on issue "Build broken when enabling fuzzing on Apple M1 hw using homebrew llvm.":
(https://github.com/bitcoin/bitcoin/issues/27550#issuecomment-1531336487)
> What is the `config.log`, or output?

```
./configure --enable-fuzz --with-sanitizers=fuzzer,address,undefined --disable-asm CC=/opt/homebrew/opt/llvm/bin/clang CXX=/opt/homebrew/opt/llvm/bin/clang++
checking for pkg-config... /opt/homebrew/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking build system type... aarch64-apple-darwin22.4.0
checking host system type... aarch64-apple-darwin22.4.0
checking for a BSD-compatible install... /opt/homebrew/bin/ginstall
...

👍 theStack approved a pull request: "test: added coverage to rpc_scantxoutset.py"
(https://github.com/bitcoin/bitcoin/pull/27453#pullrequestreview-1408953706)
ACK 24d55fb9cfab88f546df35be5c0069b9b645438c

💬 fjahr commented on issue "bitcoin core crashes when too many rpc calls are made":
(https://github.com/bitcoin/bitcoin/issues/11368#issuecomment-1531357390)
> [libevent/libevent#592](https://github.com/libevent/libevent/pull/592) has now been merged into libevent master and should provide by far the cleanest solution to our issue here. The last release was cut 5th July 2020, so perhaps a new one is due soon, although they do not seem to follow any particular schedule that I can see. I have likewise reached out to them (but on their matrix channel).
>
> I also set up a notification for new relases with a reminder to fix this issue when it lands.

...

💬 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)