docs(buglog): bug-1913 and bug-1916 fixed; log bug-1915, bug-1917, bug-1918

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-10-03 23:18:53 +00:00

2.1 KiB

Raw Blame History

status

status_updated

status_note

component

severity

timestamp

last_seen

occurrences

files

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

TODO: required for fixed/partial

Fix