| id |
status |
status_updated |
status_note |
component |
severity |
timestamp |
last_seen |
occurrences |
files |
tags |
related |
fix_commits |
gitea_issue |
gitea_synced_status |
gitea_synced_hash |
| bug-1918 |
fixed |
2026-10-04 |
|
lib |
leak |
2026-10-03T23:04:08Z |
2026-10-03T23:04:08Z |
1 |
| src/lib/xcectx.c |
| src/lib/vtaskmgr.c |
| src/controller/cluster.c |
|
|
|
|
343 |
fixed |
67e6c2e30f85 |
bug-1918: handle_msg / vtask_handle_msg early -EINVAL/-ENOMEM exits leak the received packet
Description
Observed:
Not yet observed at runtime -- found reviewing the bug-1916 fix. When handle_msg (src/lib/xcectx.c ~196-198, src/controller/cluster.c ~1371-1373) or vtask_handle_msg (src/lib/vtaskmgr.c ~617-629) returns early with -EINVAL/-ENOMEM, the received packet is still in ep->fsm_in.pkt; INVOKE_MSG_HANDLER (src/include/netio.h:148-158) then stores NULL into the slot without freeing it, so the packet leaks.
Expected: on every early exit the packet is freed exactly once (either the handler frees it, or the slot keeps it and the endpoint teardown frees it).
Impact: small per-message leak on rare error paths (allocation failure, missing context); pre-existing, not a crash.
Found by: review (bug-1916 fix, 2026-10-03)
Environment
- OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
- libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
- Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
- Build: asan (xce.build)
- Code: scheduler-framework @ 6d9ef3d0-dirty
- Deployment: any libxce client or the controller's client-request path
Reproduction
- Not reproduced; force
vtask_handle_msg to fail (e.g. allocation failure via a test hook) and check LeakSanitizer for the packet.
- Frequency: 0/1 runs, 2026-10-03 (code-review finding)
- Evidence: code reading of the cited lines
Root cause
INVOKE_MSG_HANDLER (src/include/netio.h) stored NULL into ep->fsm_in.pkt after every msg_handler call, on the old assumption that the handler always takes the packet. Since bug-1916 and raft-drive-async 3.1, a handler that takes the packet clears the slot itself (vtask_handle_msg, peer_ctrl_msg_handler). A handler that refuses it (handle_msg with no owner -> -EINVAL; vtask_handle_msg on an incomplete fsm -> -EINVAL or a failed task allocation -> -ENOMEM) leaves the packet in the slot, by the contract test_handoff_rejects_incomplete_fsm already pins. The macro's NULL store then dropped the only reference: the packet leaked.
Fix
Drop the post-handler ep->fsm_in.pkt = NULL from INVOKE_MSG_HANDLER. A refused packet stays endpoint-owned: handle_input reuses it for the next message and endpoint_fini frees it. All three production msg handlers already clear the slot when they take the packet, so no path frees it twice. The ref/unref bracket (bug-1298) is kept.
Verification
- Test:
test_refused_packet_stays_endpoint_owned (src/lib/testsuite/test_vtask_pkt_handoff.c) drives the macro with a refusing handler, then with a taking handler, then endpoint_fini. RED before the fix (slot NULL after a refusal; LeakSanitizer: 88 bytes leaked from encode_nop), GREEN and LSan-clean after.
- Suites:
xce-build.sh all asan, 127/127 meson suites OK, Go tests ok (2026-10-04).
- Live: loaded
/xce-test-ha sequential 30 rounds (40 busy loops on 32 cores), 2026-10-04: PASS, zero job loss, all 3 nodes led, no ASAN report in any controller/worker/scheduler log.
References
