Capturing a global attribute in a macro leads to leaking memory about minijinja HOT 6 CLOSED

The linked fix is not capable of fully solving this. It's just a WIP now for me to make some progress on what the actual issue is. I know now what the problem is, but I don't have a particularly nice looking solution yet.

from minijinja.

What is likely happening here is that the closure sets up a circular reference. This needs some sort of support to capture these weakly instead. I did not check yet but I believe the Arc that is not freed is this one:

The closure there holds the hello object which is the one we leak.

from minijinja.

Specifically the problem is this. When a macro is defined it stores a closure object on the context. From then on every StoreLocal also persists the value on the closure. This way a macro gains a reference to itself via the closure and a cycle is created.

from minijinja.

Trying out the PR branch, it looks like macros are still leaking memory for me. I'm on macOS and struggling a bit with Instruments to do those profiles, because for some reasons the minijinja-related symbols in stack traces don't have the source file information, so I'm trying to guess out of the allocation stack traces… But it still looks like Vm::build_macro (and in particular the Value::from_object call) is the one leaking memory. How can I help you best to debug those leaks?

from minijinja.

Commenting out the store of the caller in the context (those three lines) does cut the leak in half, so there is probably a cycle here. I'm not using the caller so I could test it in my app ; in my profiles it cuts from 28MiB to 11MiB for 250 renders.

from minijinja.

One solution might be to keep track of all created closures across an entire render call and to then break the cycles at the end. For render_to_state this cleanup would need to be deferred until the state is dropped.

from minijinja.