From 6e11ff40a257d530599c1832cdb7f6cd63dc4e1d Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Fri, 2 Oct 2026 06:03:42 +0000 Subject: [PATCH] docs(buglog): bug-1437 fixed by the librtti re-pin (8c7d26a9) Re-verified 2026-10-01: test_jobj_hardening and the full xcelib_test run clean with detect_leaks=1; meson's libxce test (abort_on_error=1) OK. Co-Authored-By: Claude Opus 5.5 (1M context) --- .wolf/buglog.json | 15 +++++++++------ .wolf/bugs/bug-1437.md | 15 +++++++++------ 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/.wolf/buglog.json b/.wolf/buglog.json index 84445b50..2bbac867 100644 --- a/.wolf/buglog.json +++ b/.wolf/buglog.json @@ -4420,18 +4420,18 @@ }, { "id": "bug-1437", - "status": "open", - "status_updated": "2026-09-24", - "status_note": "LSan leaks in test_jobj_hardening (makeInstance 240B + 7B strdup), no fix/suppression", + "status": "fixed", + "status_updated": "2026-10-02", + "status_note": "", "component": "lib", "severity": "crash", "timestamp": "2026-07-13T00:55:00Z", "last_seen": "2026-09-19T09:00:00Z", "occurrences": 2, - "error_message": "Verification run of lib build + xcelib_test --run test_jobj_hardening…\n\nVerification run of lib build + xcelib_test --run test_jobj_hardening (ASAN_OPTIONS=detect_leaks=1) after user changed 4x .datakiller=destroy -> .datakiller=dereference in src/lib/testsuite/test_jobj_hardening.c (to fix a leak in the kvmgr-of-job_t test fixture, since job_t.destroy is NULL in RTTI typeinfo and teardown only runs via job_dereference): Unity reports 5/5 PASS, 0 Failures, 0 Ignored, but LeakSanitizer STILL reports two leaks totaling 247 bytes and the process exits 1 (no halt_on_error/abort_on_error set, so no SIGABRT with plain detect_leaks=1 -- differs from the meson full-suite run which sets abort_on_error=1 and gets killed by signal 6).", + "error_message": "LeakSanitizer leaks in test_jobj_hardening (makeInstance 240 B on init failure, 7 B strdup)\n\nVerification run of lib build + xcelib_test --run test_jobj_hardening (ASAN_OPTIONS=detect_leaks=1) after user changed 4x .datakiller=destroy -> .datakiller=dereference in src/lib/testsuite/test_jobj_hardening.c (to fix a leak in the kvmgr-of-job_t test fixture, since job_t.destroy is NULL in RTTI typeinfo and teardown only runs via job_dereference): Unity reports 5/5 PASS, 0 Failures, 0 Ignored, but LeakSanitizer STILL reports two leaks totaling 247 bytes and the process exits 1 (no halt_on_error/abort_on_error set, so no SIGABRT with plain detect_leaks=1 -- differs from the meson full-suite run which sets abort_on_error=1 and gets killed by signal 6).", "file": "src/lib/testsuite/test_jobj_hardening.c", "root_cause": "TWO leaks detected, only one already known. (1) Direct leak of 240 bytes via calloc -> makeInstance -> makeJob_ (../lib/jobj.c:768) -> makeJob (../lib/jobj.c:789) -> test_job_init_propagates_makeJobsub_failure (test_jobj_hardening.c:133) -- this IS the already-diagnosed, out-of-repo makeInstance-does-not-free-on-negative-init-rc characteristic (vendored rtti library), unrelated to the datakiller fix. (2) Direct leak of 7 bytes via strdup -> hard_build_accounts (test_jobj_hardening.c:269) -> test_job_destroy_does_not_leak_accounts (test_jobj_hardening.c:328) -- this is a SEPARATE, NEW leak signature not previously logged, and it is attributed to the exact test (test_job_destroy_does_not_leak_accounts) that the datakiller=dereference fix was meant to make leak-free. NOT YET DIAGNOSED WHY: could be an unrelated small leak in the hard_build_accounts helper itself (e.g. a strdup()d account string never freed regardless of datakiller correctness), or could indicate the datakiller fix is incomplete. Not investigated further per explicit user instruction to build/run/report only, no fixing.", - "fix": "NOT FIXED IN THIS SESSION -- user explicitly instructed build+run+report only, no code changes. Logging the raw finding so the next session does not have to rediscover it: the accounts-leak test still leaks (7 bytes, strdup, hard_build_accounts) even after the .datakiller=dereference change, though it is a much smaller leak than the pre-existing 240-byte makeInstance one and does not cause any Unity test FAILURE (LSAN leak detection is a separate pass/fail axis from Unity PASS/FAIL in this harness). RECURRENCE 2026-07-16 (2nd occurrence, mechanical-validation pass for job-array-single-wal-record spec, dimension A/full-suite reconfirmation): full lib test binary run (ASan) again reports 638 PASS / 0 FAIL at the Unity level, but LeakSanitizer aborts the process at exit with the same 240-byte makeInstance->makeJob_ (jobj.c:768) leak signature, triggered via test_job_init_propagates_makeJobsub_failure (test_jobj_hardening.c:133). Confirmed this is the SAME pre-existing vendored-rtti-library characteristic already diagnosed in this entry's root_cause (1), not a new leak and not introduced by this feature's production code -- the feature's own new test is simply the first test in the suite to deliberately drive job_init() to fail after makeInstance() has already allocated, so it is the first to trip the latent characteristic. Still NOT FIXED (out of scope for a validation-only pass); flagging that under meson's full-suite invocation (abort_on_error=1) this leak turns into a SIGABRT / non-zero exit code for the lib test binary, so a naive exit-code-only CI gate would read this as a lib-suite failure even though zero Unity assertions fail and zero new markers/regressions exist in feature code.", + "fix": "Fixed 2026-07-17 by 8c7d26a9 (record not updated at the time): librtti re-pinned master 7212ba1 -> 53cf11e, where `makeInstance()` frees its calloc'd instance when the type's `.init()` returns negative. That was the 240-byte `makeInstance -> makeJob_` leak on every `job_init()` failure path (`test_job_init_propagates_makeJobsub_failure`). The commit's own verification already ran `test_jobj_hardening` clean under `detect_leaks=1:abort_on_error=1`, i.e. without the 7-byte `hard_build_accounts` leak either; e540902b (2026-07-27) re-pinned librtti again for a further package leak. No repository code change was needed.\n\nVerification:\n- Test: `xcelib_test --run test_jobj_hardening` with `ASAN_OPTIONS=detect_leaks=1` (2026-10-01, asan build `src/build.jai`): 5/5 PASS, both formerly leaking tests included, no LeakSanitizer report, exit 0; LSan confirmed active in this toolchain (a deliberate 7-byte leak in a scratch program is reported)\n- Suites: full `xcelib_test` with `detect_leaks=1`: 715/715, no leak report, exit 0; `meson test \"libxce test\"` (meson's default `abort_on_error=1`): OK, 0 `leak of` lines in the test log\n- Live: n/a (test-binary leak)", "tags": [ "jobj", "test_jobj_hardening", @@ -4449,7 +4449,10 @@ "reconfirmed" ], "related_bugs": [], - "fix_commits": [], + "fix_commits": [ + "8c7d26a9", + "e540902b" + ], "record": ".wolf/bugs/bug-1437.md" }, { diff --git a/.wolf/bugs/bug-1437.md b/.wolf/bugs/bug-1437.md index 536475d3..73002064 100644 --- a/.wolf/bugs/bug-1437.md +++ b/.wolf/bugs/bug-1437.md @@ -1,8 +1,8 @@ --- id: "bug-1437" -status: "open" -status_updated: "2026-09-24" -status_note: "LSan leaks in test_jobj_hardening (makeInstance 240B + 7B strdup), no fix/suppression" +status: "fixed" +status_updated: "2026-10-02" +status_note: "" component: "lib" severity: "crash" timestamp: "2026-07-13T00:55:00Z" @@ -11,10 +11,11 @@ occurrences: 2 files: ["src/lib/testsuite/test_jobj_hardening.c"] tags: ["jobj", "test_jobj_hardening", "leak", "asan", "lsan", "datakiller", "dereference", "hard_build_accounts", "test_job_destroy_does_not_leak_accounts", "unverified-fix", "kvmgr", "job-array-single-wal-record", "mechanical-validation", "reconfirmed"] related: [] +fix_commits: ["8c7d26a9", "e540902b"] legacy: true --- -# bug-1437: Verification run of lib build + xcelib_test --run test_jobj_hardening… +# bug-1437: LeakSanitizer leaks in test_jobj_hardening (makeInstance 240 B on init failure, 7 B strdup) ## Description Verification run of lib build + xcelib_test --run test_jobj_hardening (ASAN_OPTIONS=detect_leaks=1) after user changed 4x .datakiller=destroy -> .datakiller=dereference in src/lib/testsuite/test_jobj_hardening.c (to fix a leak in the kvmgr-of-job_t test fixture, since job_t.destroy is NULL in RTTI typeinfo and teardown only runs via job_dereference): Unity reports 5/5 PASS, 0 Failures, 0 Ignored, but LeakSanitizer STILL reports two leaks totaling 247 bytes and the process exits 1 (no halt_on_error/abort_on_error set, so no SIGABRT with plain detect_leaks=1 -- differs from the meson full-suite run which sets abort_on_error=1 and gets killed by signal 6). @@ -29,10 +30,12 @@ _Not recorded (migrated from buglog.json)._ TWO leaks detected, only one already known. (1) Direct leak of 240 bytes via calloc -> makeInstance -> makeJob_ (../lib/jobj.c:768) -> makeJob (../lib/jobj.c:789) -> test_job_init_propagates_makeJobsub_failure (test_jobj_hardening.c:133) -- this IS the already-diagnosed, out-of-repo makeInstance-does-not-free-on-negative-init-rc characteristic (vendored rtti library), unrelated to the datakiller fix. (2) Direct leak of 7 bytes via strdup -> hard_build_accounts (test_jobj_hardening.c:269) -> test_job_destroy_does_not_leak_accounts (test_jobj_hardening.c:328) -- this is a SEPARATE, NEW leak signature not previously logged, and it is attributed to the exact test (test_job_destroy_does_not_leak_accounts) that the datakiller=dereference fix was meant to make leak-free. NOT YET DIAGNOSED WHY: could be an unrelated small leak in the hard_build_accounts helper itself (e.g. a strdup()d account string never freed regardless of datakiller correctness), or could indicate the datakiller fix is incomplete. Not investigated further per explicit user instruction to build/run/report only, no fixing. ## Fix -NOT FIXED IN THIS SESSION -- user explicitly instructed build+run+report only, no code changes. Logging the raw finding so the next session does not have to rediscover it: the accounts-leak test still leaks (7 bytes, strdup, hard_build_accounts) even after the .datakiller=dereference change, though it is a much smaller leak than the pre-existing 240-byte makeInstance one and does not cause any Unity test FAILURE (LSAN leak detection is a separate pass/fail axis from Unity PASS/FAIL in this harness). RECURRENCE 2026-07-16 (2nd occurrence, mechanical-validation pass for job-array-single-wal-record spec, dimension A/full-suite reconfirmation): full lib test binary run (ASan) again reports 638 PASS / 0 FAIL at the Unity level, but LeakSanitizer aborts the process at exit with the same 240-byte makeInstance->makeJob_ (jobj.c:768) leak signature, triggered via test_job_init_propagates_makeJobsub_failure (test_jobj_hardening.c:133). Confirmed this is the SAME pre-existing vendored-rtti-library characteristic already diagnosed in this entry's root_cause (1), not a new leak and not introduced by this feature's production code -- the feature's own new test is simply the first test in the suite to deliberately drive job_init() to fail after makeInstance() has already allocated, so it is the first to trip the latent characteristic. Still NOT FIXED (out of scope for a validation-only pass); flagging that under meson's full-suite invocation (abort_on_error=1) this leak turns into a SIGABRT / non-zero exit code for the lib test binary, so a naive exit-code-only CI gate would read this as a lib-suite failure even though zero Unity assertions fail and zero new markers/regressions exist in feature code. +Fixed 2026-07-17 by 8c7d26a9 (record not updated at the time): librtti re-pinned master 7212ba1 -> 53cf11e, where `makeInstance()` frees its calloc'd instance when the type's `.init()` returns negative. That was the 240-byte `makeInstance -> makeJob_` leak on every `job_init()` failure path (`test_job_init_propagates_makeJobsub_failure`). The commit's own verification already ran `test_jobj_hardening` clean under `detect_leaks=1:abort_on_error=1`, i.e. without the 7-byte `hard_build_accounts` leak either; e540902b (2026-07-27) re-pinned librtti again for a further package leak. No repository code change was needed. ## Verification -_Not recorded (migrated from buglog.json)._ +- Test: `xcelib_test --run test_jobj_hardening` with `ASAN_OPTIONS=detect_leaks=1` (2026-10-01, asan build `src/build.jai`): 5/5 PASS, both formerly leaking tests included, no LeakSanitizer report, exit 0; LSan confirmed active in this toolchain (a deliberate 7-byte leak in a scratch program is reported) +- Suites: full `xcelib_test` with `detect_leaks=1`: 715/715, no leak report, exit 0; `meson test "libxce test"` (meson's default `abort_on_error=1`): OK, 0 `leak of` lines in the test log +- Live: n/a (test-binary leak) ## References _Not recorded (migrated from buglog.json)._