Hacker News Reader

Comment by IshKebab | Hacker News Reader

There's so much great stuff here.

First, Linux's default memory management strategy is bonkers. OOM killing rarely actually works in my experience, at least on desktop. It takes ages to kick in and usually the system just freezes and you have to hard reboot. I've experienced this on every Linux system I've used, even my current one with 128GB of RAM and 64GB of swap, so don't say "it works for me". Windows and Mac do not have this issue at all, so clearly it's possible to do it better.

Has anyone tried using strict overcommit on desktop Linux?

Second, this bug is a great counterpoint to those annoying people who naysay Rust with "but not all bugs are memory safety bugs, what about logic bugs? huh?". Rust code would not have had this bug.

View on HN

Yes, many have tried to use strict overcommit on the desktop. It is a good footgun. https://unix.stackexchange.com/a/797888/1027

That doesn't really explain why it is a footgun.

The last paragraph:

> On the modern desktop, where programmers don't care about failing malloc(), disabling overcommit is shooting yourself in the foot. As you can observe, the memory allocations start failing long before the memory is exhausted.

So it's a footgun because a lot of low quality software?

Is Firefox low quality?

Well, if Firefox also works on other OSes, it probably should gracefully handle failing allocations, isn't it?

No, it doesn't handle failing allocations gracefully - https://unix.stackexchange.com/questions/797841/firefox-died...

I lost cookies several times on disk-full condition...

If a memory allocations fails with strict mode then you'll get a null pointer returns and some kind of crash or panic (in code that doesn't handle it properly).

If it fails with the default mode the whole process will get killed by the OS. Is that really much better?

OOM is better. If a program doesn't handle ENOMEM properly, then its state is unpredictable and can lead to data corruption.

I don't think it's as simple as that. Killing a program can have unintended consequences too, e.g. corrupting files they were in the middle of writing.

What exactly does Rust solve here? Virtual memory is a hardware/OS feature.

The bug that is detailed in the article. Wouldn't have happened with Rust.

This is not a memory safety bug, but a bug resulting from a type coercion of int to bool. I don't know if Rust is stricter but your original statement was confusing.

Exactly my point. Lots of people think Rust only prevents memory safety bugs, but this is an example of a bug that isn't a memory safety bug but also wouldn't have happened in Rust.

They used an int with special meanings for negative/0/positive values. Very common in C, and not at all type safe (all meanings have the same type). In Rust you would use an enum or Result, it would be type safe and the refactoring mistake they made would have been a compile time error.

There was also a bug in the Linux kernel, or did I miss something?

Yes there was. It's detailed in the article.

But why wouldn't have happened with Rust? Sorry I can't find anything about Rust in the article. Or you mean if the Linux kernel was written in Rust and that stupid bool coercion was not possible?

It's the latter; Rust won't allow the int->bool coercion.

Though to be absolutely pedantic, !x is an int for x:int in C, there is no bool coercion involved; an if-statement takes an expression of any scalar value and evals to true on non-zero. Not that that helps to avoid introducing bugs anyway.

Because Rust programmers would have used an enum or Result.

Reply on news.ycombinator.com