---
id: "bug-1918"
status: "fixed"
status_updated: "2026-10-04"
status_note: ""
component: "lib"
severity: "leak"
timestamp: "2026-10-03T23:04:08Z"
last_seen: "2026-10-03T23:04:08Z"
occurrences: 1
files: ["src/lib/xcectx.c", "src/lib/vtaskmgr.c", "src/controller/cluster.c"]
tags: ["leak", "vtask", "netio"]
related: ["bug-1916"]
fix_commits: ["a74b684c"]
gitea_issue: 343
gitea_synced_status: "fixed"
gitea_synced_hash: "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
1. 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
- Related: none