loadCore leaks export_fns and cached_fns when the start function traps

[jtakakura]

Description

In WasmModule.loadCore (src/types.zig), export_fns and cached_fns are allocated before the Wasm start function is executed.
If the start function traps (or otherwise returns an error), the errdefer chain cleans up vm, instance, wasi_ctx, module, store, and self, but never frees export_fns or cached_fns.

This is a narrow, pre-existing resource leak discovered during the review of #40. It is unrelated to the OOM-on-VM fix in that PR.

Steps to reproduce

1. Prepare a Wasm module whose start function always traps (e.g., unreachable) and has at least one exported function so that export_fns / cached_fns are non-empty.

Example WAT:

(module
  (func $start unreachable)
  (func (export "dummy") (result i32) i32.const 0)
  (start $start)
)

2. Load it under a leak-checking allocator:

var gpa = std.heap.GeneralPurposeAllocator(.{ .safety = true }){};
defer _ = gpa.deinit(); // reports leak
_ = WasmModule.loadFromWat(gpa.allocator(), wat_source) catch {};

3. Observe that gpa.deinit() reports memory leaks for export_fns (including the inner param_types / result_types slices) and cached_fns.

zwasm version

1.8.0

Platform

Linux x86_64

Additional context

No response

[chaploud]

@jtakakura Thanks for the careful report.

The fix landed in PR #57. WasmModule.loadCore now has errdefer entries for export_fns and cached_fns that mirror the order in deinit, so the failure path is symmetric with normal teardown. When the start function traps after the export caches are built, the slices and their inner param_types / result_types arrays are now properly freed.

Your reproduction recipe (unreachable start + a non-empty export + a leak-checking allocator) was added verbatim as a regression test in src/types.zig, asserting no leaks via testing.allocator.

The fix ships in v1.11.0, just released:
https://github.com/clojurewasm/zwasm/releases/tag/v1.11.0

v1.10.0 → v1.11.0 also includes W46 (link_libc=false restoration on the core build) and W48 Phase 1 (binary size trim, ceiling re-tightened to 1.60 MB), so you may notice a smaller binary as well. Thanks again for the report!