About processes freeing up memory/causing memory leaks in an aborting panic

[Oakchris1955]

LearnixOS-Book/src/ch01-01-making-stand-alone-binary.md

Lines 212 to 213 in 71e783a

	When a program panics, usually because of an unrecoverable error, it has to stop whatever it is doing. In a normal execution environment with neighboring programs, all of the program's memory should be cleaned up so a memory leak doesn't occur on the operating system[^4]. This is where _unwinding_ comes in.
	[^4]: Some operating systems may not free up memory when terminating a program, and may assume it is the program responsibility to free up all memory before exiting.

To my knowledge (and per various Rust books and some Reddit threads), the scope of unwinding isn't to not leak memory, at least in modern Rust, because back in the day, and quoting the first Rust book:

In the long-long-ago, Rust was much more like Erlang. Like Erlang, Rust had lightweight tasks, and tasks were intended to kill themselves with a panic when they reached an untenable state. Unlike an exception in Java or C++, a panic could not be caught at any time. Panics could only be caught by the owner of the task, at which point they had to be handled or that task would itself panic.

Unwinding was important to this story because if a task’s destructors weren’t called, it would cause memory and other system resources to leak. Since tasks were expected to die during normal execution, this would make Rust very poor for long-running systems!

Nowadays, unwinding seems to exist mainly so that object destructors (Drop trait) can be executed before the program exits and to provide a stack backtrace for where a panic occurred. I found some claims that in real-time operating systems, an aborting panic could cause memory leaks, but other than that, it seems that the vast majority of operating systems mark the memory of a terminated process as free.