Ask the allocator what the engine never got back

[tamnd]

The leaks item off the clients scorecard, which is the last piece of apparatus this client owes. Sanitizer and leak jobs in CI, because a binding holds native memory and the process that finds out later is the user's.

Why the suite cannot answer this

A test that closes nothing and asserts on a message passes. There is no Cleaner behind this client and nothing waits for a collector, which the API documents rather than apologises for, so a handle that is dropped stays open until the process ends and no allocator in Java will ever call it garbage: the pointer is still reachable from a live object. That makes an allocator outside the JVM the only thing that can see the mistake.

The narrow question

Pointing LeakSanitizer at a JVM that does nothing at all reports about a megabyte in several thousand allocations. All of it is the JVM's own, and it is not a bug: an exiting process has an operating system to give its pages back, and a shutdown that walks them is time spent for nobody.

So the question this asks is not "did anything leak". It is "of the blocks nobody freed, is any of them one the engine allocated", which is answerable, because a leak record carries the stack it came from.

Frame #1, and what the JNI row taught

Matching any frame in the stack is wrong, and the JNI provider is where that shows. Asking for a jmethodID allocates a JVM-side table entry the JVM never frees, and the stack for it runs through the shim, because the shim is what asked. Any-frame matching called seven of those ours on a clean run. At frame #1 they are os::malloc in libjvm, and frame #1 is whoever called malloc, since #0 is the sanitizer's own interceptor.

A block the shim really did allocate has the shim at #1 and is still caught, which is why the shim is named in the filter at all. The count of records let through is printed on every run rather than dropped quietly, so a decision this script made is a decision somebody can argue with.

The gate

A report with no libzu in it looks the same whether nothing leaked, the sanitizer was never loaded, the library was never called, or the driver exited early. Three of those four are green for the wrong reason.

So the driver runs first with ZU_LEAK_GATE=1, which drops a database, a connection, a statement, a result, an appender and a frame on the floor on purpose, and the script stops if that comes back clean. This is the same shape as zu-go's internal/leakgate, run first for the same reason.

What it did on server3

Both providers, against libzu built from the engine at HEAD:

	Panama	JNI
gate, records allocated by us	57	57
clean run, records allocated by us	0	0
clean run, records in total	545	390
clean run, records that only pass through us	0	7
what the JVM itself left	1,344,160 bytes	334,637 bytes

The gate records name zu_execute, zu_appender_open and zu_database_open. The full reactor is green beside all of it: 199 tck cases on Panama, 12 Arrow, BUILD SUCCESS.

What is in here

zudb-tck/src/main/java/dev/zudb/tck/Leaks.java is the driver, and it lives in the tck because both providers owe the same answer. It runs an in-memory database with a frame the engine reads where it lies, a database on disk with a prepared statement, three appenders that end three different ways, a transaction and a duplicated connection, then the same handles on the paths that never reach the end: a syntax error, an undefined variable, a column read as the type it is not, a row past the end, a value the appender refuses. The failures are the half that matters, because a close that is never reached is the shape a leak has here.

scripts/leaks.sh finds the runtime and the symbolizer, builds the driver and one provider, and runs the gate and then the clean pass. ASAN_OPTIONS turns off handle_segv and allows a user handler, because a JVM uses the faults its own handlers catch as ordinary control flow and a sanitizer that takes those first turns a working JVM into a crash on the first query.

The CI job runs both providers on Linux. Linux only: LeakSanitizer does not exist on macOS, and what covers the same ground on the darwin rows is the lifecycle half of the misuse suite, which counts open file descriptors either side of a few hundred failures and needs no allocator to agree with it.

The engine is not built with the sanitizer, deliberately. Interposing the allocator is enough to see a block nobody freed, and an instrumented engine would mean building the whole of Rust twice to answer a question about this repository.

The scorecard

That is 80 to 90 on practice for this client, which is the tier 1 threshold. What is left is api-map and perf, which are reports the release collects rather than apparatus, and zu-python, zu-node and zu-go are missing the same two.