lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(buglog): bug-1437 fixed by the librtti re-pin (8c7d26a9)

Browse source 
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) <noreply@anthropic.com>
This commit is contained in:
Rongsong Shen 2026-10-02 06:03:42 +00:00
parent ce729b5fad
commit 6e11ff40a2
Signed by untrusted user: rshen
GPG key ID: 80533536B0EB651C
2 changed files with 18 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

15
.wolf/buglog.json
View file

@ -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"
},
{

15
.wolf/bugs/bug-1437.md
View file

@ -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)._