Conversation

John-Mark Gurney

@encthenet

May 24

😭😭😭 "It turns out that, according to Rust’s rules, leaking memory is completely safe!"

Quote Tweet

Lily Mara

@TheLily_Mara

May 23

We ran into a production memory leak issue with one of our high-throughput Rust systems, check out what we found in my new post on the @onesignal blog: onesignal.com/blog/solving-m #rustlang

Replying to

Creating a non-weak reference cycle, etc. isn't memory or type unsafety which is what the unsafe feature is used to contain in Rust. It would cripple expressiveness of some things in safe code like Rc<T> and Arc<T> if leaking had to be considered memory / type unsafe.

Replying to

and

It doesn't mean Rust considers leaking memory correct or that it doesn't make it difficult. It means it doesn't force you to prevent APIs like Rc<T> and Arc<T> from allowing people to leak memory in safe code. If it was considered unsafe, those would have to prevent those cycles.

Replying to

and

Preventing reference cycles would require having very strict type bounds for Rc<T> and Arc<T> to forbid reference counted types nested within reference counted types. Cripples what you can express and would mean you need unsafe code to do something that's type and memory safe.

Replying to

and

The language considering detaching stuff from scope-based ownership with reference cycles, etc. as unsafe also wouldn't prevent you having unbounded memory growth. It'd only prevent doing it in a way that wouldn't be freed as part of returning / unwinding back through main.

Replying to

A) I don't know enough rust to understand what you said, but B) there's a fix underway to address this to teach the language that it's unsafe to do this (mentioned in the article) so it can be "made safe".

Replying to

The article is mixing up the terms undesirable / incorrect with unsafe. The term unsafe in Rust means something specific: type / memory unsafe. Safe Rust doesn't mean bug free or correct code. It simply means code where memory and type unsafety bugs are prevented by the language.

Replying to

Yeah, problem is many rust people make that same confusion as well. This seems to make that same confusion: doc.rust-lang.org/book/ch00-00-i I couldn't find a proper definition of safe in the rust book. I avoided all the advanced features search results because it shouldn't be there.

Replying to

The safe subset of Rust prevents type unsafety, memory unsafety, non-atomic data races, etc. It doesn't disallow splitting off resources from the call stack ownership tree but it makes it very hard to do it by accident. Disallowing it would have been possible, but inconvenient.

Replying to

Please get this added to the rust book in a prominent place so that people learning the language can learn where the sharp edges are.

Daniel Micay

@DanielMicay

Replying to

@encthenet

I wouldn't really call this a sharp edge. You can leak memory in Go, Python or Java. The places where it needs to be documented are Rc<T> and Arc<T> which need to explain that strong reference cycles will leak and you should be using Weak<T> to create weak references for cycles.

1:13 AM · May 24, 2022Twitter Web App

Replying to

and

The only thing that's a sharper edge than a GC language is that reference counted types will leak cycles instead of a GC coming along to collect them. It's worth noting that until relatively recently, CPython leaked reference cycles if anything in that cycle had a __del__ method.

Replying to

and

Rc<T> and Arc<T> are a bit harder to use correctly for self-referential types than doing the same thing in a garbage collected language where you don't need to use weak references as often. Weak references are still useful with GC though, particularly weak ref collection types.

Show replies