Explanation needed

Am I to understand that after all Rust isn't that "Memory safe language" and leaks all over the place?

No, that would be the wrong conclusion. Rust doesn't guarantee that code without unsafe blocks have no leaks, but accidentally writing code that leaks memory is still very rare.

I have not read the RFC in detail, but it appears to be an attempt to, in some situations, guarantee that certain values really are destroyed.

1 Like

Up until now I was convinced that that was one of the three qualities of rust:
Safe, reliable and easy.
Surely, having memory leaks means that is neither safe nor reliable?
Disappointing doesn't even begin to describe...

Tbh I was convinced that this is the case EVERY time. Now I read something different.
Quite disappointing...

I don't think it really deserves to be called unreliable because of this. The only situation that can cause a memory leak is when you combine both Rc and RefCell to build a cycle of Rcs.

I have used Rust for five years and have seen a real unintentional memory leak twice.

2 Likes

I'm sorry but I have to disagree with you.
If Rust leaks, then it cannot be called neither safe nor reliable.
Yes, it happened to you twice. To others will happen more. And more, and more...
Leaking means not safe and not reliable. Nothing else.

See: https://stackoverflow.com/a/56108074/

You understand that preventing all possibilities of leaking is impossible, right? The SO answer gives the example of adding to a Map. The only thing that can be done is to make it highly unlikely that it occurs by accident. And of course leaking intentionally will always be allowed.

3 Likes

Rust certainly has those qualities.

Not to my mind.

"safe"in Rust has a rather specific meaning. Mostly (all) to do with use of memory. That everything one references: exists, initialised, is of the right type, is owned/borrowed correctly, etc. Thus eliminating segfaults and randomly wrong results/behaviour through misuse of memory.

As such, and as far as I can see, leaking memory is not unsafe. Leaked memory satisfies all the safety criteria above. It's just been forgotten about.

Don't be so disappointed.

By using Rust you are already in a place a couple of orders of magnitude safer, more reliable, and easy than say C or C++.

As it happens, I would have to go out of my way to create a memory leak in Rust. Off the top of my head I don't know how to do it. Except I know it can be done with mutually referencing structs using Rc.

3 Likes

Yes, I know that. Non the less. If something leaks is neither safe nor reliable.

Reliable is a spectrum of course, but I can't think of any language that is more reliable than Rust, except perhaps something like F* where your program includes a mathematical proof of correctness.

2 Likes

Leaking memory can bring system down. Don't you think that this isn't neither safe nor reliable? What if the functioning of the system was critical to keep somebody alive?
We have to disagree here.

Being the most reliable (assuming that is true) is rather different to: Safe, reliable.
The whole premise of Rust was that it is completely memory safe and reliable except within "unsafe" blocks. Now it turns out that this isn't true.
To me it is simply very, very disappointing...

There is a list of things considered undefined behavior, which includes things such as use-after-free or data races, and those really are guaranteed for code that does not use unsafe, but the list does not include memory leaks.

The decision to not include memory leaks in that list was made because actually making that guarantee for real has some quite significant consequences on what language features are possible for the language to provide.

Still, the language is very very good at avoiding leaks, and something like a hash-map that keeps having new keys added to it without ever removing anything is much more likely to be the cause of you running out of memory than a real memory leak.

3 Likes

An infinite number of possible bugs can "bring down" the system.

Faulty logic in my code could output the wrong value of something, thus not applying the brakes on an anti-lock brake system, delivering a lethal dose of medicine to a patient, flying a plane into a mountain, etc, etc.

Or perhaps it just hangs in an endless loop never to make any forward progress again.

I am no computer science student but my understanding is that formally verifying bugs do not happen is theoretically impossible. At least Turing said something about that problem of finding endless loops.

Or at least, formal verification is so hard and so demanding of computer resources we don't often try to do it.

I, for now at least, put memory leaks into the same category as all those other infinite number of bugs one can write in ones code.

More philosophically, nothing is "safe", ever. For example cars have anti-lock brakes, airbags, and all kind of other safety features. Yet still people get injured and killed by cars. Machine tools have safety guards and emergency cutouts, etc, yet still people manage to incur themselves with them. And so on.

So yes, we will have to disagree. Because your definition of "safe" includes guaranteeing the complete absence of bugs. Which is not possible.

5 Likes

Slow down. As with nearly every one of your many low-quality posts, this has been discussed before. Take a minute to consider what others are saying. Search for past posts on this topic (I assure you there are many). Look into the history of things a bit. Don't feel the need to respond to every person within a minute or two. Rather, take a step back and consider another viewpoint. That's good advice in general, not just for this situation.

6 Likes

I do take a time to read, but I don't have to think when somebody posts something like this to know that this is not true:

There are things that the compiler cannot realistically verify. Leaking memory is one of those things. It was meant to be unsafe for a while I think, until this became clear.

Depending on what you expect memory safety to mean, there might be many more ways to break it in safe Rust. For example, you can depend on a thirdparty library that wrongly exposes unsafe things in a safe interface, then you don't have to write any unsafe code yourself to break memory safety.
Or you open /proc/self/mem on a Linux system where your code runs, and write random stuff to it. (kernel - How do I read from /proc/$pid/mem under Linux? - Unix & Linux Stack Exchange)

None of this means that Rust violates memory safety by the definition established for it. You are free to call that definition useless, but it clearly has a lot of value in practice. I've never heard about memory leaks in a Rust program causing practical issues. It's always invalid unsafe code, in application or library code, that causes memory related bugs.

1 Like

You clearly are not taking the time to read, because I explicitly said to read up on the history and previous posts. Had you done so, you would know why leaking memory is not considered to violate memory safety. I strongly urge you to take a step back and perform some research of your own volition.

2 Likes

Accidentally leaking memory with Rust is harder than to do so with Java or Python due to its ownership semantics, but still is possible. Honestly I haven't heard any turing-complete language which guarantee to prevent memory leak. Would it even be possible?

3 Likes