Can Zig's test runner detect resource leaks?

pqsrc · April 29, 2025, 3:43pm

If you use std.testing.allocator, the test runner will detect memory leaks and print stack traces. But memory is not the only resource. You can leak in other ways:

Call openFile, but never call File.close
Call process.Child.spawn, but never call kill or wait
Call Thread.spawn, but never call join or detach
Call myUserCodeStart, but never call myUserCodeEnd

Does Zig have any way to sanitize for these kinds of leaks?

Sze · April 29, 2025, 4:02pm

I think this might make it so that we can do similar detection, for some of those other resources:

But the last one seems like it would require some sort of custom validation tooling, or adding support for validation, unless you also invent some sort of interface convention for your myUserCodeStart functions.

Southporter · April 29, 2025, 4:02pm

It is not currently implemented, but the core team is planning to handle these use cases.

github.com/ziglang/zig

File descriptor leak checking

opened 01:51AM - 24 Aug 20 UTC

daurnimator

standard library proposal accepted

I've found some resource leaks in code due to missing `file.close()` calls. As …a debug feature, we should be able to detect this and at least throw an error in tests. Implementation ideas: - <s>(debug mode only): global linked list of file descriptors: objects like `std.fs.File` could add themselves to the list on open and remove on `.close()`</s> - (debug mode only): global var containing array of known file descriptors -> stack frames. On `exit` iterate the array and show tracebacks for which fds were leaked - (release-safe mode and debug mode): global atomic counter incremented on `open` and decremented on `close`. Check for equality at start/end of tests.

dimdin · April 29, 2025, 4:36pm

github.com/ziglang/zig

Add a handle leak checker to `std.testing` and/or the test runner

opened 09:24PM - 27 Jul 23 UTC

squeek502

enhancement standard library

This is mostly just to gather feedback on the viability/usefulness of this sort …of thing. I'm also unsure how many platforms this could be implemented for. --- While trying to confirm that some code was leaking some file handles on Windows, I wrote the following code: ```zig pub const HandleLeakChecker = struct { initial_count: u32, pub fn init() HandleLeakChecker { return .{ .initial_count = getCurrentCount() }; } pub fn delta(self: HandleLeakChecker) i64 { return @as(i64, @intCast(getCurrentCount())) - self.initial_count; } pub fn getCurrentCount() u32 { if (builtin.os.tag == .windows) { const process_handle = std.os.windows.kernel32.GetCurrentProcess(); var count: u32 = undefined; const result = std.os.windows.kernel32.GetProcessHandleCount(process_handle, &count); std.debug.assert(result != 0); return count; } return 0; } }; ``` and used it like so: ```zig const handle_leak_checker = std.testing.HandleLeakChecker.init(); var dir = try tmp_dir.dir.makeOpenPath("root_dir/parent_dir/some_dir", .{}); dir.close(); const delta = handle_leak_checker.delta(); if (delta != 0) { std.debug.print("file handle delta: {}\n", .{delta}); return error.HandlesLeaked; } ``` I think this sort of thing would be nice to have in `std.testing`, but I can't think of a way to make it nicer to use. One almost-nice way to use it would be with defer and `std.debug.assert` or `@panic` ```zig var handle_leak_checker = std.testing.HandleLeakChecker.init(); defer std.debug.assert(handle_leak_checker.delta() == 0); // or defer if (handle_leak_checker.delta() != 0) @panic("handles leaked"); ``` but this doesn't give feedback about how many handles were leaked and it seems like returning an error would be better for this sort of thing (but returning an error rules out the possibility of using `defer`). EDIT: Actually, this might be pretty decent: ```zig pub const HandleLeakChecker = struct { // ... pub fn check(self: HandleLeakChecker) !void { const handles_delta = self.delta(); if (handles_delta != 0) { std.debug.print("Handles were leaked or lost, handle count delta: {}\n", .{handles_delta}); return error.TestLeakedHandles; } } } test { // ... const handle_leak_checker = std.testing.HandleLeakChecker.init(); var dir = try tmp_dir.dir.makeOpenPath("root_dir/parent_dir/some_dir", .{}); dir.close(); try handle_leak_checker.check(); } ``` --- Another way to go (or an addition) would be to have the test runner use this for every test (similar to how `std.testing.allocator` checks for leaks for you). This seems like it'd be pretty nice from a user perspective (they wouldn't have to do anything at all and get handle leak checking for free), but I may be missing some reason that test cases might need to leak handles.

pqsrc · May 1, 2025, 1:29pm

Thanks for the links!

rockorager · May 1, 2025, 1:42pm

I actually just mentioned this on IRC but I would think that the IO abstraction will make this pretty easy to implement.