Does the OS not clean up the stack on a panic?

[gaunt basalt]

In https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html it says:

by taking an action that causes our code to panic […] or by explicitly calling the panic! macro, […] we cause a panic in our program. By default, these panics will print a failure message, unwind, clean up the stack, and quit.

My question is, what happens to the stack if abort on a panic, instead unwinding? This will make Rust not clean up the stack, but is that not what the OS does anyway after a process ends? Will the allocated memory in the stack (and heap) just stay there until I reboot the computer?

[barren prawn]

The OS does clean up most of the time. Some things may require manual cleanup to be done in a different way

In practice, you can just assume the OS will clean up and you'll be right often enough that it won't matter

[gaunt basalt]

Can you name one or two things that may require manual cleanup, as an example?
The OS allocates memory for a process, right? So what happens when some memory is not cleaned up. Is the memory blocked from being re-allocated to other processes? Or is the data in the memory just kept as is -- meaning that there is a risk that another process can read whatever was stored there before the rust application panicked and aborted?

I'm trying to understand the concrete downside or risk when the stack is not cleaned up.

[barren prawn]

Cursed edge-case OS-specific APIs (there's at least one thing in windows that is OS-global and will not be cleaned up for you). Unless you go out of your way to look for these, you won't find them

More commonly, database connections.

IIRC they usually do get cleaned up, but that might take a while

Mostly because the database could be on a server, so your program is taking up server resources, and the OS won't clean up resources on another computer

[gaunt basalt]

That makes sense.

So what happens when some memory is not cleaned up. Is the memory blocked from being re-allocated to other processes? Or is the data in the memory just kept as is -- meaning that there is a risk that another process can read whatever was stored there before the rust application panicked and aborted?
I'm trying to understand the concrete downside or risk when the stack is not cleaned up.

Can you answer that as well?

[warped trellis]

I may be wrong here, but one example I can think of is when using threads:
If a thread panics, it doesn't crash the process, it only aborts the thread. The OS wouldn't be able to free that memory (how would it know you have no references to it?), so this is something the "user" has to do