TIL: Rust does not prevent memory leaks

&gt; People talk so much about Rust memory safety and how everything must be rewritten in Rust, but if Rust does not prevent memory leaks why are people so crazy about it?<p>The primary goal of rust is to provide a low-overhead, low-level language which is <i>memory safe</i> without the need for a runtime. Memory leaks are not a memory safety concerns[0], although they can cause programs to crash they are not UBs, they don&#x27;t cause grave vulnerabilities (they might lead to DOS but not something like a compromised device)..<p>Furthermore while the Rust team and community discovered they could not reasonably prevent memory leaks[2], at least not without a very different languages and years if not decades of development, a normally constituted program is unlikely to have <i>unintended</i> leaks[1], the main vehicle to get that being a refcount cycle.<p>[0] although in Rust the realisation that leaks could not be prevented did force the reconsideration and binning of entire APIs because they could not be <i>made</i> safe anymore<p>[1] since it was realised that leaks were a fact of life, the standard library added a few APIs whose entire purpose is to leak objects<p>[2] much to everyone&#x27;s dismay and displeasure, I assume you can still look for &quot;leakpocalypse&quot; for recountings of the events

Memory safety is not about memory leaks. It&#x27;s concerned with the corruption of data structures, particularly the stack and the heap.<p>To elaborate a little, consider security. If your software&#x27;s only vulnerability is potential memory leaks, an attacker can only get away with denial-of-service attacks. If your software is vulnerable to buffer overflows, an attacker can use return-oriented programming to get arbitrary code execution, exfiltrate all your data, and add your machine to a botnet to perform subsequent attacks on yet other systems.

To add to what was said, one of the main ways to leak memory is `Box::leak` [0], meaning most memory leaks are explicit and intentional, rather than implicit and accidental. Likely the main implicit&#x2F;accidental way to leak memory are Rc cycles.<p>Looks like <a href="https:&#x2F;&#x2F;cglab.ca&#x2F;%7Eabeinges&#x2F;blah&#x2F;everyone-poops&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cglab.ca&#x2F;%7Eabeinges&#x2F;blah&#x2F;everyone-poops&#x2F;</a> has more background on why this is allowed.<p>[0]: <a href="https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;std&#x2F;boxed&#x2F;struct.Box.html#method.leak" rel="nofollow">https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;std&#x2F;boxed&#x2F;struct.Box.html#method.l...</a>

The &quot;Memory Safety&quot; of Rust is not that memory leaks are not possible, rather its how memory is accessed. Specifically, using &quot;safe&quot; Rust, it should be impossible to:<p>1. Access memory that hasn&#x27;t been explicitly allocated to your program 2. Access memory that was was previously allocated and freed by your program 3. Access memory that could be modified by a separate thread &#x2F; function of your program, outside of some locking mechanism.<p>I&#x27;m sure there&#x27;s a more academic definition, and stronger guarantees, but those are the basics.<p>Now, these guarantees impose restrictions on how code is written, and runtime overhead to enforce. There are many cases where a human can write optimizations and ensure those guarantees in a way the compiler cannot verify. This is why Rust has an &quot;escape&quot; of writing &quot;unsafe Rust&quot;, where the compiler does validate those guarantees. Unsafe Rust includes expanded primitives, such as &quot;Box::leak()&quot;, that enable writing these optimizations, and may explicitly leak memory without maintaining a reference<p>If a program is written using purely safe Rust, it should not be possible for a malicious input &#x2F; request to corrupt internal data structures, read memory that shouldn&#x27;t be read, or all the other &quot;interesting&quot; things that get highlighted by Heartbleed and other big security vulnerabilities.<p>Note that I say &quot;should not be possible&quot; - the Rust compiler can and has had bugs that break those memory safety guarantees under certain conditions. They aren&#x27;t common, but it&#x27;s unfair to say &quot;Rust is perfect and 100% safe&quot;<p>I strongly recommend everyone learn Rust, at least to the point where you &quot;grok&quot; the borrow checker and what it&#x27;s trying to enforce, even if you have no intention with regularly using Rust. After learning Rust, I found the patterns the borrow checker enforces incredibly useful when writing C++, and ensuring I don&#x27;t make silly memory mistakes that may result in a crash or vulnerability.

You&#x27;re conflating memory safety and memory usage&#x2F;management. Safe Rust prevents you from addressing or accessing arbitrary memory, null pointer dereferencing, and buffer overflows, while remaining performant relative to other memory safe languages (e.g. Java, Python, Go, Ada, etc). In particular, it doesn&#x27;t have a Garbage Collector.<p>There is no actual difference between a memory &quot;leak&quot; and intentionally allocated memory except the INTENT of the developer. It is important for good language design to avoid accidental memory leaks via well-designed constructs. Ultimately there will always need to be a mechanism for a developer to create a block of allocated memory and free it only on their schedule.<p>Rust&#x27;s language design does make it harder to leak memory, and well written Rust would rarely do so. However, if Rust made arbitrary allocations impossible, certain use cases would also be nearly impossible and performance for others would suffer greatly (e.g. allocating a buffer ahead of time, for the lifetime of a worker). It is a balance, at some point you have to trust the developer to make decisions.

Memory leaks are different from memory safety. What people are talking about is that Rust helps prevent the use of memory that wasn&#x27;t intended. That&#x27;s the big win there.<p>Disclaimer: I am not a fan of Rust, this is just my understanding of this aspect of the benefits of it.

(Not a regular rust developer, so take this with a large grain of salt)<p>Rust can absolutely prevent memory leaks. It depends on how much unsafe rust code you use. Many rust developers find the convenience outweighs the risk of leaks, and take the tradeoff offered by the `Rc` type.

This is the kind of post I see on Reddit. I don&#x27;t really understand what this is doing on the front page, it is a low effort question, OP says it doesn&#x27;t have any clues about how Rust works and has apparently spent 0 time searching about it.

I daresay any Turing-complete language will be unable to prevent all memory leaks, since the simplest memory leak is just using more memory intentionally and never letting any of it go. Unless you want to eliminate resizable data structures like linked lists, growable arrays, trees, and hash tables, you can always leak memory.<p>What Rust and most other modern languages do is make it very difficult to <i>unintentionally</i> and&#x2F;or <i>unknowingly</i> leak memory. There are times when even this can&#x27;t be guaranteed without breaking other constraints (e.g. one of the solutions to the setenv unsafety issue involves leaking memory instead), but they are rare and documented.

Rust does help to prevent memory leaks, but it is not considered a soundness bug to leak memory, whereas it is a soundness bug to (e.g.) use memory after it is freed.<p>Historically, what happened in Rust is that shortly before 1.0 was released, someone found a situation where you could get a reference-count cycle with the standard container types, and there was a lot of consternation as to whether or not this was actually a bug. This is termed the &quot;leakpocalypse.&quot; The ultimate resolution was to accept that destructors are not guaranteed to be run, and therefore the kind of leak that was created is not actually a bug.

Yes, you are not alone in being surprised by this. Another thing that sometimes surprises people is deadlocks, and maybe the <i>Fearless Concurrency</i> slogan is partially to blame.<p>To Rust&#x27;s defense, both are extraordinary hard problems, and Rust&#x27;s tooling is better than that of other languages in the space.<p>For memory leaks we have (above and beyond the usual suspects from the C&#x2F;C++ world like valgrind) the leak detection in MIRI. For deadlocks we have the parking_lot crate.

Memory leaks aren&#x27;t unsafe generally, unless they are triggered in a way that could lead to DoS attack.<p>That&#x27;s not memory safety that rust advertises.

As already said, Rust puts guards when using memory. Forget what everyone is doing and start writing some programs - from simple to advanced - to understand what Rust is all about. There are some great resources (TRPL, books, blogs, YT videos, playgrounds etc) out there that should get you going.<p>Think in terms of sharing memory across threads and what you need to do to avoid contention, use after free, races etc - and you will realize Rust helps you avoid all of that - and more.<p>Granted Rust has its idiosyncracies - which language doesn’t?<p>Try Rust yourself and don’t worry about the hype and what others are saying. Using LLMs would help you understand, write, troubleshoot some advanced concepts. We live in an amazing time where this is possible. Take full advantage of this.

std::mem::forget() explicitly leaks a resource, including memory[1]. The whole point is to allow circumventing running a destructor. There&#x27;s also Box::leak() to quite explicitly leak memory[2]. Handy for dynamically allocating memory that needs to live for the remainder of the program (making `&#x27;static` lifetimes at runtime).<p>[1] <a href="https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;std&#x2F;mem&#x2F;fn.forget.html" rel="nofollow">https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;std&#x2F;mem&#x2F;fn.forget.html</a><p>[2] <a href="https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;std&#x2F;boxed&#x2F;struct.Box.html#method.leak" rel="nofollow">https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;std&#x2F;boxed&#x2F;struct.Box.html#method.l...</a>

Rust <i>does</i> prevent memory leaks, however memory leaks are still possible, as they are in any language. Is it even possible for a language to make memory leaks impossible? A memory leak is different from safety, btw.

Why is this flagged?