Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The library can leak #41

Closed
dbuenzli opened this issue Apr 26, 2024 · 1 comment · Fixed by #42
Closed

The library can leak #41

dbuenzli opened this issue Apr 26, 2024 · 1 comment · Fixed by #42

Comments

@dbuenzli
Copy link

It's not entirely evident from the zlib docs but once you have called the {inflate,deflate}Init function you need to have a call to {inflate,deflate}End otherwise you will leak internally allocated structures.

As such the finalizer here should be adapted (perhaps easiest is to have a different finalizer for inflate and deflate initialized streams).

The following loops can be used to exhibit the behaviour:

let rec loop_leak () = ignore (Zlib.inflate_init false); loop_leak ()

let rec loop_noleak () =
  let s = Zlib.inflate_init false in
  Zlib.inflate_end s; loop_noleak ()

let () = loop_leak ()
xavierleroy added a commit that referenced this issue Apr 30, 2024
Otherwise, a memory leak occurs if `Zlib.deflate_end` / `Zlib.inflate_end`
were not called before the `Zlib.stream` became unreachable.

Also: use `caml_alloc_custom_mem` instead of `caml_alloc_custom`.

Fixes: #41
@xavierleroy
Copy link
Owner

Well spotted. Proposed fix at #42 .

xavierleroy added a commit that referenced this issue Jun 6, 2024
Otherwise, a memory leak occurs if `Zlib.deflate_end` / `Zlib.inflate_end`
were not called before the `Zlib.stream` became unreachable.

Also: use `caml_alloc_custom_mem` instead of `caml_alloc_custom`.

Fixes: #41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants