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

and

Leaking memory isn't type or memory unsafe. The language already makes it hard to leak memory due to automatic resource management based on scopes. You can leak by creating a reference cycle, so there's a function to do it on purpose more efficiently since it can be useful.

Replying to

and

For example, it can be a performance optimization to skip calling a bunch of destructors on the way to exiting the program. It's also often used in low-level building blocks. That utility used to be unsafe but it made no sense, since you can write it making an Rc<T> cycle.

12:56 AM · May 24, 2022Twitter Web App

Replying to

and

One trivial way to make a reference cycle is to make a type T with a field Option<Rc<T>>, then make one and put it inside Rc<T> followed by cloning that to put it in the field. You've created a strong reference cycle, splitting it off from the call scope ownership system.

Replying to

and

It's possible to prevent this in Rust's type system and the original Rc<T> that I implemented did exactly that, but leaking memory just doesn't meet any reasonable definition of type/memory unsafety. It'd just force using unsafe code for self-referential reference counting types.

Show replies