Leak when binding a stack closure #2036

brson · 2012-03-21T01:41:43Z

This example from the language reference leaks

fn main() {
    fn add(x: int, y: int) -> int {
        ret x + y;
    }

    type single_param_fn = fn(int) -> int;

    let add4: single_param_fn = bind add(4, _);
    let add5: single_param_fn = bind add(_, 5);

    assert (add(4,5) == add4(5));
    assert (add(4,5) == add5(4));
}

Unreclaimed object found at 0x678b7a0: ((), (5))
Unreclaimed object found at 0x678b730: ((), (4))
rust: fatal, 'leaked memory in rust main loop (2 objects)' failed, ../src/rt/memory_region.cpp:158 2 objects

The text was updated successfully, but these errors were encountered:

marijnh · 2012-03-21T13:33:29Z

For me (on Linux) this program doesn't leak and is Valgrind-clean.

brson · 2012-03-21T18:49:24Z

I dug a little deeper and the problem is with declaring the type as a stack closure. Here's a reduced test:

fn main() {
    fn add(x: int) {
    }

    let add4: fn() = bind add(4);
}

Declaring add4 as fn@() works

nikomatsakis · 2012-04-07T14:31:33Z

Interesting. I can see why this fails, yes. The problem is that we have no cleanup for fn() types (and rightly so)... we assume that an fn() variable is an alias for an fn@() somewhere else. So here the problem is when we upcast the fn@() to an fn().

This is in fact a borrowing operation (a la regions) and I can probably fix this bug at the same time as I implement borrowing more generally.

nikomatsakis · 2012-04-07T14:33:44Z

Actually, the simpler fix is just to prevent fn() from being stored in a local variable---just as we do with fn&().

catamorphism · 2012-06-22T02:54:22Z

Obsolete, since we no longer have bind ( #2189 ). Closing.

…ang#2246) This change allows us to pin-point exactly which build artifacts are related to a cargo build run. This is required to re-enable the build cache (rust-lang#2036) where multiple artifacts can co-exist in the same folder. The solution implemented here is rather hacky, but it's more reliable than other alternatives I've tried (see model-checking/kani#2246). Now, `kani-compiler` will generate stubs in the place of binaries, shared, and static libraries when those types are requested. Those stubs will contain a JSON representation of the new type `CompilerArtifactStub`, which basically contain the path for the `metadata.json` file where the compiler stores the metadata related to a given crate. `kani-driver` will parse `CompilerArtifact` messages to figure out which artifacts were built for the given build. For libraries, it will derive the name of the metadata file from the `rmeta` filepath. For other types of artifacts, it will parse the output file, convert it to `CompilerArtifactStub`, and extract the path for the `rmeta` filepath.

…#2036)

ghost assigned nikomatsakis Apr 7, 2012

thatmattbone mentioned this issue Apr 22, 2012

stack closure leak #2270

Closed

catamorphism closed this as completed Jun 22, 2012

Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024

Add advice about submitting potentially hard-to-review PRs (rust-lang…

5d108d4

…#2036)

bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025

Add advice about submitting potentially hard-to-review PRs (rust-lang…

06343bb

…#2036)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Leak when binding a stack closure #2036

Leak when binding a stack closure #2036

brson commented Mar 21, 2012

marijnh commented Mar 21, 2012

brson commented Mar 21, 2012

nikomatsakis commented Apr 7, 2012

nikomatsakis commented Apr 7, 2012

catamorphism commented Jun 22, 2012

Leak when binding a stack closure #2036

Leak when binding a stack closure #2036

Comments

brson commented Mar 21, 2012

marijnh commented Mar 21, 2012

brson commented Mar 21, 2012

nikomatsakis commented Apr 7, 2012

nikomatsakis commented Apr 7, 2012

catamorphism commented Jun 22, 2012