[Bug]: Memory leak when invoking functionality from a WASM plugin

[stahlbauer]

Describe the bug

I have written a plugin that uses the metadata.source_map to guide some decisions. Calling methods of this object, in particular span_to_snippet, leads to a memory leak.

Here is an example of a plugin that reproduces the issue:

#[plugin_transform]
pub fn process_transform(
    mut program: Program,
    metadata: TransformPluginProgramMetadata,
) -> Program {

    for i in 1..50000 {        
        let j: u32 = i;
        println!("i {} j {}", i, j);
        metadata.source_map.span_to_snippet(Span::new(BytePos(j), BytePos(j+10), SyntaxContext::empty()));
    }

    program
}

I have used this plugin in my test environment which invokes it two times. This results in the following memory graph:

Removing the loop also eliminates the memory leak.

Note that I am using a version of SWC that allows for using the full 4GB of WASM memory---see #6378 .

Input code

No response

Config

No response

Playground link

No response

Expected behavior

The memory should be freed after use.

Actual behavior

No response

Version

1.3.14

Additional context

No response

[kwonoj]

I'm bit unsure if this is expected amount of pressure or if there's an actual leak. If leak is true, it'll be probably allocated buffer in the wasm memory space is not explicitly freed somewhere.

[stahlbauer]

@kwonoj Are you planing to address this proactively? Which means are currently in place to free memory allocated in context of sharing data between the native process and the WASM world?

[kwonoj]

Need confirmation on #6404 (comment) .

[stahlbauer]

Do you need this confirmation from me? In which form? I would have to get into WASM memory management first to understand the foundations.

Generally, I would not call the observable behavior a desired behavior :-) What I learned is that WASM does not do garbage collection. So where should the "pressure" come from?

[stahlbauer]

See, for example, https://www.oreilly.com/library/view/what-is-webassembly/9781492076902/ch04.html#:~:text=WebAssembly%20doesn't%20have%20a,for%20managing%20allocation%20of%20memory.

[kwonoj]

I meant someone. If I have some time I could, but I can't promise anything.

I am aware wasm / rust both are not GC collectable. But there still can be pressure if some memories are allocated in very short time frame, which is example code does exactly. The exact thing need to be confirmed is an evidence allocated memory is not dropped correctly once it is completed used and goes out of the scope from plugin transform.

[stahlbauer]

Thanks for the clarification. Just wanted to ensure that you are not waiting for exactly my confirmation (which could delay fixing this significant issue without intent).

[kdy1]

I investigated this, and it seems like this happens only if the value sent from the host to the plugin is Err

(To be exact, it seems like it requires to be out of range)

[kdy1]

My mistake, I can't reproduce this with --nocapture
Maybe a large file required?

[kdy1]

With a large file, I can reproduce with Ok, and the plugin halts after 4.21GB

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.