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.

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

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".

Show replies