mirror of
https://github.com/hanzoai/datastore.git
synced 2026-09-26 13:55:07 +00:00
Groene AI
08aad5330f
The `tests/fuzz/execute_query_fuzzer.options` file had `timeout = 20`, the per-input libFuzzer wall-clock budget. Combined with the `max_execution_time = 10` cap in the same file (which only bounds query execution, not pre/post-execution work), this is too tight on ASan ARM fuzzer runners for inputs that produce deeply nested types such as `Array(Array(Array(...)))`. The destructor cascade for such types is a chain of recursive calls through `SerializationArray::~SerializationArray` -> `shared_ptr<ISerialization>` deleter -> `SerializationObjectPool::getOrCreate(...)::$_0::operator()` (`src/DataTypes/Serializations/SerializationObjectPool.cpp:87`) -> `delete ptr;` -> next inner `SerializationArray::~SerializationArray` ... Each level acquires `pool.mutex` once and pays for ASan `__sanitizer_cov_trace_cmp8` + `BufferedStackTrace::UnwindFast` instrumentation around the `operator delete` site, so the walltime cost is `O(depth * sanitizer-overhead)` even after the `max_execution_time = 10` cap has already returned an empty pipeline. Recent CIDB (`test_name = 'execute_query_fuzzer'`, last 30 days) shows 13 hits across 11 unrelated PRs: - 7 crashes (`deadly signal`) - 5 timeouts (`timeout after 20-30 seconds`) - 1 OOM (`out-of-memory; used: 4259Mb; limit: 4096Mb`) The timeout shape on PR #100930 commit `9322b0ec` is the `SerializationObjectPool` cascade described above — visible in the trace: https://s3.amazonaws.com/clickhouse-test-reports/PRs/100930/9322b0ec86ee5ca6e2690cdc8a0e611d55947800/libfuzzer_tests/execute_query_fuzzer/timeout-68e661ff4168a4b4e495567db2c9f1128c594c85.trace Raising the per-input timeout to 60s matches the precedent set for `select_parser_fuzzer` in #105188 (just merged) and gives the destructor cascade headroom on slow sanitizer runners while keeping a hard ceiling. The cap on real work is `max_execution_time = 10`, not this timeout; the timeout just needs to outlive the cap plus sanitizer-instrumented teardown. Refs: - Open issue #93438 ("libFuzzer tests are flaky") - Sibling fix #105188 (`select_parser_fuzzer` timeout bump) - Report PR=100930: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=100930&sha=9322b0ec86ee5ca6e2690cdc8a0e611d55947800&name_0=PR&name_1=libFuzzer%20tests
13 lines
209 B
Plaintext
13 lines
209 B
Plaintext
[libfuzzer]
|
|
timeout = 60
|
|
dict = all.dict
|
|
rss_limit_mb = 4096
|
|
|
|
[fuzzer_arguments]
|
|
s3_retry_attempts=1
|
|
max_execution_time=10
|
|
http_connection_timeout=1
|
|
http_send_timeout=1
|
|
http_receive_timeout=1
|
|
http_max_tries=1
|