mirror of
https://github.com/hanzoai/datastore.git
synced 2026-09-26 13:55:07 +00:00
Alexey MilovidovandClaude Opus 4.7
a413287a0c
The `tests/fuzz/select_parser_fuzzer.options` had `timeout = 20`, the per-input libFuzzer wall-clock budget. Combined with the `max_parser_backtracks = 10000` cap from PR #104922, this is fine on release builds (the parser bails in ~0.16s on pathological deeply-nested SELECT inputs) but not on ASan ARM CI runners: those exec at ~18-42/s, so the parser needs >20s of wall time to hit the backtrack cap and abort with `TOO_SLOW_PARSING`. libFuzzer kills the process first and reports `timeout-*` artefacts. Recent CIDB (test_name='select_parser_fuzzer', last 7 days) shows the fuzzer failing on many unrelated PRs every day with timeouts of 20-29s, matching this exact pattern. Example artefact from PR #96130: https://s3.amazonaws.com/clickhouse-test-reports/PRs/96130/8e0106f5809257b068a61a001f58042689b005ab/libfuzzer_tests/select_parser_fuzzer/timeout-49fccbae556e7a03ed5e64d5c08cb55653bb10ce (524-byte malformed SELECT with deeply nested parens and WITH/SELECT chains; reproduces the timeout class from closed issue #92282.) Raising the per-input timeout to 60s gives the backtrack cap room to fire on slow sanitizer/cross-arch runners while keeping a hard ceiling. The cap, not the timeout, is what bounds real worst-case parse work; the timeout just needs to outlive it. Refs: - Open issue #93438 ("libFuzzer tests are flaky"). - Closed issue #92282 (`select_parser_fuzzer` timeout on deeply nested parens) — same input class still surfacing on ASan ARM. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
7 lines
91 B
Plaintext
7 lines
91 B
Plaintext
[libfuzzer]
|
|
timeout = 60
|
|
dict = all.dict
|
|
|
|
[fuzzer_arguments]
|
|
max_parser_backtracks = 10000
|