Right, this is a problem with reference counted data structures in general. You're correct that Rust doesn't try to solve this particular problem.

Put differently, the borrow checker won't allow you to create a cycle of refrences (the & kind). But you can do it with library types such as Rc.

It's a property of basic RC but real-world RC based GC systems can often collect reference cycles. For example Python and PHP do this.

(I'm sure you knew this, just adding to the discussion)

Rust doesn’t though. But it does make it much harder to leak memory than C. You need to create a cycle between reference counted objects versus just forget to free something.

Not that it matters as much as people think. Memory leaks aren’t a correctness problem. You typically want to restart a program or service regularly anyway to deal with memory fragmentation. You also frequently have a watchdog like systemd to restart your program if it crashes. Heroku restarts your whole dyno once a day. This means in practice that programs with slow memory leaks tend to work just fine (there are plenty of them in the wild.)

Interesting view that memory leaks aren't correctness problems. But I would require more convincing to agree.

It's true that memory leaks can be small enough that they don't become problems in the end-to-end behaviour of the system in regular use. But a lot of bugs are like that. For example many memory safety bugs.

> Interesting view that memory leaks aren't correctness problems.

The view of rust is rather that they’re not safety problems.

Whether they’re correctness problems is more complicated: in general they are, but there are lots of cases where they’re not, like short-running processes (once the process terminated it’s memory is reclaimed so freeing it is unnecessary overhead), or FFI (you’re moving memory out of your purview, you can’t know whether it’ll be disposed of anymore).

Safety and security as terms have an interesting relationship especially in Rust context - traditionally in engineering safety means defending against accidents and security means defending against malicious attackers, but "safety" in the term "memory safety" commonly implies security as well. Language is hard...

Considing whether memory leaks are a security problem brings us to the traditional CIA definition of security - the A (availability) is at risk from memory leaks.

Sorry, I should have said they’re not safety problems. The commenters below got it right.

Memory safety bugs are very different, because whether or not they affect the functioning of your software, they’re a ticking time bombs that could compromise your system. A memory leak will at worst crash your software.

It does not guarantee, but it is actually quite hard to cause a memory leak by accident, because at the same time Rust makes creating cycles hard.

I actually haven't tried this... do you know off the top of your head what it takes to make a cycle with Rc?

It should not be possible with normal borrows (and safe Rust) since they're statically checked to be acyclic.

The Rust Book has an example: https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Of course, leaking memory is as easy as using `Box::leak`, although that's probably never going to happen accidentally.

You could store a `RefCell<Option<T>>` in an `Rc` and set it to `Some(rc)` after creation.

Or you could use the recently-stabilized `new_cyclic` method: https://doc.rust-lang.org/std/rc/struct.Rc.html#method.new_c...

And when using C libraries / FFI, there are a lot of tricky things going in, it is much easier to leak in unsafe land.