3 ms·

Meanwhile, bryan lunduke blogged this today: https://lunduke.substack.com/p/massive-memory-leaks-in-system76s https://lunduke.substack.com/p/massive-memory-leak

Meanwhile, bryan lunduke blogged this today: https://lunduke.substack.com/p/massive-memory-leaks-in-system76s https://lunduke.substack.com/p/massive-memory-leaks-in-syste...

demurgos 2y ago
I haven't finished listening yet; but it should be made clear that Rust claimed to prevent double frees and use-after-free errors but never claimed to prevent memory leaks. Memory leaks were actually decided to be fully safe just before Rust 1.0, and there are multiple safe methods to leak memory. Search for "leakpocalypse" if you want more details. I also spent the day fixing a memory leak in an Angular (JS) project: you can create memory leaks in almost any language, including memory-safe ones (even garbage-collected ones). The tone of the podcast seems needlessly incendiary. EDIT: He actually quotes a part of the doc were they say that "memory leaks are hard but still possible". It's disappointing that Cosmic has leaks; but it's more about Cosmic than the language IMO.
- lblume 2y ago
  You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. The "easiest" way to do it accidentally would be an Rc loop, but that is harder to write than Rc::new_cyclic which gives you the memory-correct Weak reference. When you stick to a fully owned tree memory model (or use bump allocators for fancier data structures) things usually turn out very easy, and I pretty much never had to worry about this.
  - demurgos 2y ago
    > You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. It's true if you stick to the standard library, but I assume that the Cosmic frameworks adds a layer of complexity. I'm not familiar with their codebase, but I can easily see how an Rc cycle can appear behind a system with lots of shared references (e.g. callbacks, GUI components with backlinks, etc.). You can also get memory leaks through caches without a clear eviction policy. You can also get cases of "memory amplification" where you hold an Rc to a larger struct despite only needing a tiny amount of data from it. Basically, I agree that the standard library tries to steer you away from memory leaks. However, I also understand that it's not foolproof and can see how you can get in a situation with leaks when your approach is to take some tech debt to avoid short-term delays.
remram 2y ago
Leaking memory is not what is referred to as "memory unsafe". This is clickbait.
mplanchard 2y ago
Memory leaks have nothing to do with memory safety. This is covered in most introductory Rust material. It is in fact trivial to leak memory with Box::leak()
- tpoacher 2y ago
  Interesting, I actually didn't know this. Not a rust developer obviously. It does sound like the kind of factoid that should be super upfront though. Half the "better than c" comments I see here always seem to hint about c memory leaks being the big problem that rust comes to fix. So if it's not that, I honestly don't know what is being referred to by memory safety in this context then.
  - NobodyNada 2y ago
    "Memory safety" is referring to safety from null-pointer dereferences, use-after-frees, buffer overflows, data races, invalid pointer casts, etc. Safe Rust has no undefined behavior. Memory leaks are bad but they don't cause undefined behavior (your program might use more memory than it needs, but an attacker can't gain remote code execution from a memory leak). So Rust has tools (such as RAII) to help prevent accidental memory leaks, but it doesn't guarantee absolute freedom from memory leaks.
  - deleted 2y ago
    [deleted]
  - mplanchard 2y ago
    It's fairly up front in this portion of "the book," which is the standard learning material for new Rust programmers: https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
  - mplanchard 2y ago
    Re: comments about relative safety to C, I don't know specifically what kind of comments you're talking about, but Rust's memory safety guarantees are: - No data races: it is impossible in safe Rust for two threads to simultaneously mutate memory without appropriate guards - No reads/writes from memory that is not owned/allocated - Any location in memory may only have a single mutable reference at a time (and any number of immutable references) Combined, you eliminate a large class of memory-related bugs, including use-after-frees, double frees, and buffer under/overflows.

Meanwhile, bryan lunduke blogged this today: https://lunduke.substack.com/p/massive-memory-leaks-in-system76s https://lunduke.substack.com/p/massive-memory-leaks-in-syste...

demurgos 2y ago

I haven't finished listening yet; but it should be made clear that Rust claimed to prevent double frees and use-after-free errors but never claimed to prevent memory leaks. Memory leaks were actually decided to be fully safe just before Rust 1.0, and there are multiple safe methods to leak memory. Search for "leakpocalypse" if you want more details. I also spent the day fixing a memory leak in an Angular (JS) project: you can create memory leaks in almost any language, including memory-safe ones (even garbage-collected ones). The tone of the podcast seems needlessly incendiary. EDIT: He actually quotes a part of the doc were they say that "memory leaks are hard but still possible". It's disappointing that Cosmic has leaks; but it's more about Cosmic than the language IMO.

lblume 2y ago
You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. The "easiest" way to do it accidentally would be an Rc loop, but that is harder to write than Rc::new_cyclic which gives you the memory-correct Weak reference. When you stick to a fully owned tree memory model (or use bump allocators for fancier data structures) things usually turn out very easy, and I pretty much never had to worry about this.
- demurgos 2y ago
  > You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. It's true if you stick to the standard library, but I assume that the Cosmic frameworks adds a layer of complexity. I'm not familiar with their codebase, but I can easily see how an Rc cycle can appear behind a system with lots of shared references (e.g. callbacks, GUI components with backlinks, etc.). You can also get memory leaks through caches without a clear eviction policy. You can also get cases of "memory amplification" where you hold an Rc to a larger struct despite only needing a tiny amount of data from it. Basically, I agree that the standard library tries to steer you away from memory leaks. However, I also understand that it's not foolproof and can see how you can get in a situation with leaks when your approach is to take some tech debt to avoid short-term delays.

remram 2y ago

Leaking memory is not what is referred to as "memory unsafe". This is clickbait.

mplanchard 2y ago

Memory leaks have nothing to do with memory safety. This is covered in most introductory Rust material. It is in fact trivial to leak memory with Box::leak()

tpoacher 2y ago
Interesting, I actually didn't know this. Not a rust developer obviously. It does sound like the kind of factoid that should be super upfront though. Half the "better than c" comments I see here always seem to hint about c memory leaks being the big problem that rust comes to fix. So if it's not that, I honestly don't know what is being referred to by memory safety in this context then.
- NobodyNada 2y ago
  "Memory safety" is referring to safety from null-pointer dereferences, use-after-frees, buffer overflows, data races, invalid pointer casts, etc. Safe Rust has no undefined behavior. Memory leaks are bad but they don't cause undefined behavior (your program might use more memory than it needs, but an attacker can't gain remote code execution from a memory leak). So Rust has tools (such as RAII) to help prevent accidental memory leaks, but it doesn't guarantee absolute freedom from memory leaks.
- deleted 2y ago
  [deleted]
- mplanchard 2y ago
  It's fairly up front in this portion of "the book," which is the standard learning material for new Rust programmers: https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
- mplanchard 2y ago
  Re: comments about relative safety to C, I don't know specifically what kind of comments you're talking about, but Rust's memory safety guarantees are: - No data races: it is impossible in safe Rust for two threads to simultaneously mutate memory without appropriate guards - No reads/writes from memory that is not owned/allocated - Any location in memory may only have a single mutable reference at a time (and any number of immutable references) Combined, you eliminate a large class of memory-related bugs, including use-after-frees, double frees, and buffer under/overflows.