BLOCKER: owned RawBuf never dropped — drop call not emitted at scope end (slab leak) #43
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
An owned
RawBufwhose lifetime ends inside a function body is never dropped: codegen emits@drop_raw_buf_RawBufbut emits no call to it at the owner's scope end. Every such buffer leaks its slab. Harmless for a one-shot program, accumulates in a loop. This is the true defect behind the #42 symptom — #42's stated root cause (uniqueness-table binder-name collapse under shadow-rebind) was disproven empirically (see the comment on #42).Minimal reproducer
examples/raw_buf_drop_min.ail— a single owned 1-slot Int RawBuf, written once and read once:Prints
10correctly, but underAILANG_RC_STATSshowsallocs=2 frees=1 live=1— the slab leaks.RED test (already in the working tree, uncommitted)
crates/ail/tests/e2e.rs::raw_buf_owned_drop_balances_rc_stats— builds the fixture with--alloc=rc, assertsstdout == "10"(green) andlive == 0(RED until fixed).Evidence it is binder-independent (not #42's cause)
Measured under
AILANG_RC_STATS:raw_buf_int.ail(3×let buf)live=1b0/b1/b2/b3live=1letat alllive=1The fully inline form
(app RawBuf.get (app RawBuf.set (new RawBuf (con Int) 1) 0 10) 0)produces byte-identical leaking IR. With no binder there is nothing for the(def_name, binder_name)key to collapse, so the leak cannot be a uniqueness-table name issue.emit-irshowsmain's body as:@drop_raw_buf_RawBufis defined but never called. The two allocs are the slab + theint_to_strstring fromprint; the one free is the string'src_dec.Suspected area / next step
The owned-RawBuf drop-emission decision in
crates/ailang-codegen(drop / let-close path). First suspect: the(intrinsic)/intercept interplay for RawBuf — the drop function is synthesised but its call site is not emitted for an owned RawBuf at scope end. Needs adebuggerroot-cause pass against the minimal reproducer before any fix is planned. Approach A from #42 is not the fix.Relationship to #42
#42 should be reframed or closed in favour of this issue. The raw-buf.5 spec section (
docs/specs/0054-raw-buf.md) is mis-scoped against both diagnoses and needs a fresh brainstorm. raw-buf.6 (kernel_stub retirement) remains after.refs #7