Concept ACK

is there a failing example test case that we can run to verify it is enabled in debug mode?

Or should these invariants be unreachable for extenral users?

Partial Tested ACK fe565fb (can't say anything about the configure.ac flag details, which I don't know anything about )

is there a failing example test case that we can run to verify it is enabled in debug mode?

I tried to dereference an iterator to an entry of an empty mempool:

BOOST_AUTO_TEST_CASE(mempool_iterator_ub)
{
    CTxMemPool pool;
    LOCK2(cs_main, pool.cs);
    typename CTxMemPool::indexed_transaction_set::index<descendant_score>::type::iterator it = pool.mapTx.get<descendant_score>().begin();
    std::string txId{it->GetTx().GetHash().ToString()};
}

This fails for me on this branch with

(...)Assertion `safe_mode::check_dereferenceable_iterator(*this)' failed.

and passes on master. Triggering other codes from safe_mode::error_code (see link in OP) should be possible too.

FWIW, executing the unit tests for debug builds doesn't take significantly longer with this patch on my machine:

The benchmark ComplexMemPool is slower by a factor of roughly 3 compared to a --enable-debug build on master.
PR:

Master:

Would it make sense to enable this also for fuzzing, or do the existing sanitizers already cover these error conditions anyway?

@MarcoFalke any thoughts?

I think google oss-fuzz has --enable-debug turned on? Also, there might be a CI task in the qa-assets repo that has it turned on.

you should turn it on for fuzzing, i can think of some implementations that might not be caught in existing sanitizers (e.g., imagine as an optimization deleting a key puts the cleared object in a valid but not initialized 'orphanage' for a future allocation to use -- the iter might be invalid but not a memory fault to access afterwards).

i dont think the code actually does this, but the internal safe mode would catch these things.

Oh, I was wrong. OSS-Fuzz does not run with --enable-debug. https://github.com/google/oss-fuzz/blob/aa83381257bbf55d71c6a4b0f56f805409776047/projects/bitcoin-core/build.sh#L57

It only runs with DEBUG=1, but this is disabled due to bugs (:smiling_face_with_tear: ): https://github.com/google/oss-fuzz/blob/aa83381257bbf55d71c6a4b0f56f805409776047/projects/bitcoin-core/build.sh#L33

I am running --enable-debug somewhere else: https://github.com/MarcoFalke/btc_nightly/blob/0b191f4cb53134217f992908a0f5962dcc05b6f7/00_setup_env_native_fuzz_enable_debug.sh#L17

Though that also fails currently due to a boost bug (:smiling_face_with_tear: ): https://cirrus-ci.com/task/6626378031300608?logs=fuzz_run#L947

If you enable it for fuzzing in this repo, the mempool test might take three times as long. (https://cirrus-ci.com/task/4976712239808512?logs=ci#L4448) From 30 minutes to 90 minutes. Not sure if this will push us over the 120 minute timeout.

Rebased this given #24558 has been merged.

Guix builds

Rebased and simplified.

Looks like this doesn't affect the fuzz runtime too much, so should be fine.

Concept and code review ACK 06e18e0