3 ms·

Couldn't the language demand that, as long as a memory chunk is allocated and not freed, there's a path to use this memory chunk? Meaning it's not a memory leak

by hiq 6y ago

Couldn't the language demand that, as long as a memory chunk is allocated and not freed, there's a path to use this memory chunk? Meaning it's not a memory leak in the sense of 'we are certain (we could prove) that this memory chunk will never be used again', such as the std::mem::forget mentioned elsewhere in the thread. In practice that would mean that you need to write some formal proof, but that doesn't seem impossible. Just like some formal languages require that you write a termination proof to define a recursive function. Of course I'm not saying this is a practical solution for a language like Rust to demand this kind of proofs for every program, but since programs written in a subset of C have been formally verified, it should be possible (and sometimes desirable) for Rust too.

zesterer 6y ago
This is actually pretty easy to do, and indeed vanilla Rust does sort of guarantee that memory leaks can't happen, at least when using its normal ownership rules. However, Rust's standard library also includes types (implemented with unsafe code, but only accessible through safe interfaces) that allow shared ownership through reference-counting like `Rc`/`Arc` and also ways to mutate shared memory like `RefCell`/`Mutex`. These two things, in combination, allow the creation of self-referential data (i.e: effectively a leak). For this reason, it's necessary to consider leaking a safe (if generally unintended) behaviour. After all, leaking isn't "undefined behaviour" and it generally isn't intrinsically harmful to the program, except at the limit when the computer runs out of memory in which case you get a safe, well-defined OOM panic. Heck, there are even a plethora of useful techniques that use leaking. Leaking a data structure proves to the compiler that it will stay around indefinitely (i.e: it has a "static" lifetime), for example, which allows you to do things with it that Rust would normally forbid. That is not to say that Rust doesn't provide any protection from leaking, however. Its ownership model generally makes leaking extremely difficult to do accidentally, particularly when designing programs idiomatically, and its standard library contains a variety of abstractions that aid in managing shared memory correctly without leaks (Weak RC references, reference swapping, etc.). I don't think I've personally ever experienced a leak-related problem that wasn't a result of badly-considered unsafe code despite the fact that I've been writing Rust every day for about 5 years and as my day job for the last 2 of those.
- hiq 6y ago
  > Leaking a data structure proves to the compiler that it will stay around indefinitely (i.e: it has a "static" lifetime), for example, which allows you to do things with it that Rust would normally forbid. Asking as a Rust neophyte: are you saying that one thus declares a static lifetime without using the static lifetime name (https://doc.rust-lang.org/stable/rust-by-example/scope/lifetime/static_lifetime.html https://doc.rust-lang.org/stable/rust-by-example/scope/lifet...)? In which case would you do one way over the other then?
  - steveklabnik 6y ago
    The type signature of the leak function is pub fn leak<'a>(b: Box<T>) -> &'a mut T where T: 'a, If T is owned, or only contains ‘static references itself, then ‘a must also be ‘static. Does that help at all?
kybernetikos 6y ago
Most of my programming has been in various garbage collected languages, where indeed the language ensures that there's a path to use allocated memory, and if not, it gets rid of it. It doesn't stop you leaking memory though. You can store stuff in a map and then never get it out again, and depending on what you're doing, that sort of thing can be surprisingly common.
vlovich123 6y ago
Allocate memory and assign to a global that’s never actually used. Boom. Memory leak. Make that global a vector to leak larger amounts of memory more easily. Rust doesn’t have a GC which would be needed to make the guarantee you’re looking for at runtime (and even still, GC’d languages can be made to leak memory as well as far as I’m aware).

by hiq 6y ago

zesterer 6y ago

This is actually pretty easy to do, and indeed vanilla Rust does sort of guarantee that memory leaks can't happen, at least when using its normal ownership rules. However, Rust's standard library also includes types (implemented with unsafe code, but only accessible through safe interfaces) that allow shared ownership through reference-counting like `Rc`/`Arc` and also ways to mutate shared memory like `RefCell`/`Mutex`. These two things, in combination, allow the creation of self-referential data (i.e: effectively a leak). For this reason, it's necessary to consider leaking a safe (if generally unintended) behaviour. After all, leaking isn't "undefined behaviour" and it generally isn't intrinsically harmful to the program, except at the limit when the computer runs out of memory in which case you get a safe, well-defined OOM panic. Heck, there are even a plethora of useful techniques that use leaking. Leaking a data structure proves to the compiler that it will stay around indefinitely (i.e: it has a "static" lifetime), for example, which allows you to do things with it that Rust would normally forbid. That is not to say that Rust doesn't provide any protection from leaking, however. Its ownership model generally makes leaking extremely difficult to do accidentally, particularly when designing programs idiomatically, and its standard library contains a variety of abstractions that aid in managing shared memory correctly without leaks (Weak RC references, reference swapping, etc.). I don't think I've personally ever experienced a leak-related problem that wasn't a result of badly-considered unsafe code despite the fact that I've been writing Rust every day for about 5 years and as my day job for the last 2 of those.

hiq 6y ago
> Leaking a data structure proves to the compiler that it will stay around indefinitely (i.e: it has a "static" lifetime), for example, which allows you to do things with it that Rust would normally forbid. Asking as a Rust neophyte: are you saying that one thus declares a static lifetime without using the static lifetime name (https://doc.rust-lang.org/stable/rust-by-example/scope/lifetime/static_lifetime.html https://doc.rust-lang.org/stable/rust-by-example/scope/lifet...)? In which case would you do one way over the other then?
- steveklabnik 6y ago
  The type signature of the leak function is pub fn leak<'a>(b: Box<T>) -> &'a mut T where T: 'a, If T is owned, or only contains ‘static references itself, then ‘a must also be ‘static. Does that help at all?

kybernetikos 6y ago

Most of my programming has been in various garbage collected languages, where indeed the language ensures that there's a path to use allocated memory, and if not, it gets rid of it. It doesn't stop you leaking memory though. You can store stuff in a map and then never get it out again, and depending on what you're doing, that sort of thing can be surprisingly common.

vlovich123 6y ago

Allocate memory and assign to a global that’s never actually used. Boom. Memory leak. Make that global a vector to leak larger amounts of memory more easily. Rust doesn’t have a GC which would be needed to make the guarantee you’re looking for at runtime (and even still, GC’d languages can be made to leak memory as well as far as I’m aware).