The Sanitizer Build job has been failing on main since 512d168d (the audit mode-transition/grouping follow-up to #613), and still fails on the 0.42.2 tag.
Failing runs:
All 41 assertions in test_audit_log pass — the failure is LeakSanitizer catching a real leak at process exit, deterministic across both runs:
==ERROR: LeakSanitizer: detected memory leaks
SUMMARY: AddressSanitizer: 669 byte(s) leaked in 21 allocation(s).
The leaking allocations all trace back through fail_one_json_allocation (the new malloc-fault-injection hook) to test_audit_settings_allocation_failures_do_not_drop_mode_changes at test_audit_log.c:1306, i.e. the call to handle_put_audit_settings():
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#1 fail_one_json_allocation test_audit_log.c:1284
#2 cJSON_CreateArray
#3 test_audit_settings_allocation_failures_do_not_drop_mode_changes test_audit_log.c:1306
Indirect leak of 384 byte(s) in 6 object(s) allocated from:
... cJSON_CreateString
Indirect leak of 128 byte(s) in 2 object(s) allocated from:
... cJSON_CreateObject
The test sweeps fail_at across every allocation index in one handle_put_audit_settings() call, so this reproduces at whichever index lands after modes are already published (failure_after_mode_publish) — i.e. somewhere in the success-path response construction (respond_audit_settings() and/or the changes/details cJSON objects in handle_put_audit_settings()), where a forced allocation failure leaves an already-built cJSON object unreachable from anything that gets cJSON_Delete'd on that path. I haven't pinned the exact line yet — flagging now with the reproducible evidence rather than sitting on it; will follow up with a fix.
Local repro: build Debug with ASan+UBSan (-DENABLE_LITERT=OFF needed here since XNNPACK doesn't compile under GCC 14 in this environment — unrelated to this leak) and run ./build/bin/test_audit_log directly, or ctest -R '^test_audit_log$' with ASAN_OPTIONS=detect_leaks=1.
The Sanitizer Build job has been failing on
mainsince512d168d(the audit mode-transition/grouping follow-up to #613), and still fails on the0.42.2tag.Failing runs:
All 41 assertions in
test_audit_logpass — the failure is LeakSanitizer catching a real leak at process exit, deterministic across both runs:The leaking allocations all trace back through
fail_one_json_allocation(the new malloc-fault-injection hook) totest_audit_settings_allocation_failures_do_not_drop_mode_changesat test_audit_log.c:1306, i.e. the call tohandle_put_audit_settings():The test sweeps
fail_atacross every allocation index in onehandle_put_audit_settings()call, so this reproduces at whichever index lands after modes are already published (failure_after_mode_publish) — i.e. somewhere in the success-path response construction (respond_audit_settings()and/or thechanges/detailscJSON objects inhandle_put_audit_settings()), where a forced allocation failure leaves an already-built cJSON object unreachable from anything that getscJSON_Delete'd on that path. I haven't pinned the exact line yet — flagging now with the reproducible evidence rather than sitting on it; will follow up with a fix.Local repro: build Debug with ASan+UBSan (
-DENABLE_LITERT=OFFneeded here since XNNPACK doesn't compile under GCC 14 in this environment — unrelated to this leak) and run./build/bin/test_audit_logdirectly, orctest -R '^test_audit_log$'withASAN_OPTIONS=detect_leaks=1.