2

There are many questions on Stack Overflow asking about how a system handles memory leaks and what happens on abnormal termination. Examples:

https://stackoverflow.com/questions/6727383/dynamically-allocated-memory-after-program-termination

https://stackoverflow.com/questions/10223677/when-a-program-terminates-what-happens-to-the-memory-allocated-using-malloc-that

https://stackoverflow.com/questions/2975831/is-leaked-memory-freed-up-when-the-program-exits

However, I could not find any posts asking the same about memory corruption. Is handling of memory leaks and memory corruption by the Linux kernel the same? When the process exits, are the corrupted segments of memory freed and reclaimed, and are they safe to use by other processes?

Also, what about processes using POSIX shared memory (/dev/shm)? From my understanding it seems that shared memory does not get reclaimed by the system unless it is deleted by shm_unlink. (http://man7.org/linux/man-pages/man7/shm_overview.7.html) Does this mean that if shared memory segment somehow gets corrupted then the user is basically screwed until they reboot the system? Or will kernel clear the shared memory by shm_unlink automatically on user logout (without rebooting) after all user processes get killed?

Thanks!

Improve this question
2
  • 2
    What exactly do you mean with memory corruption? A hardware fault? Buggy software writing unexpected values? Something else?
    – ilkkachu
    Jun 10, 2017 at 9:41
  • I apologize, I should have been more specific. I mean corruption of virtual memory (heap/stack) used by a process caused by buggy software.
    – Arnold
    Jun 10, 2017 at 10:11

2 Answers 2

Reset to default
3

When a process dies, its memory is reclaimed by the operating system. It's marked as free, and will be allocated to other processes sooner or later when other processes require memory. The memory is always wiped before being allocated to a process.

It doesn't matter that there's been memory corruption in the process. The concept of memory corruption is in the context of the execution of the process — it means that the content of the memory is not what the programmer intended. When the process is dead, this concept is no longer meaningful. The same goes for a memory leak: all the memory of the process is reclaimed when it exits.

Shared memory is an exception to this because it doesn't belong to any single process. When a process exits, all that gets reclaimed is the process's handle on the shared memory; the shared memory itself remains until it's explicitly removed. Think of a shared memory object as a file that lives purely in memory and isn't attached to the filesystem. It's like a temporary file without a name.

A process that uses shared memory should clean it up before exiting. Preferably, if a process uses shared memory, it should be run by a supervisor process, and the supervisor should clean up resources such as shared memory and temporary files if the main process crashes.

Improve this answer
3
  • Thank you for the detailed explanation, this answers my question in most part! There's one more thing I would like to ask concerning shared memory handling. For example, Google Chrome's multi process architecture apparently uses shared memory for IPC between the browser and its tabs. Let's say that some memory bug causes the main browser process to crash and all of its child processes get killed without having a chance to unlink shm. If you then restart the browser, would the new browser process have a way to access the old shm segments or would it create new ones to use in that session?
    – Arnold
    Jun 11, 2017 at 7:54
  • 2
    If you use shared memory, you can shm_unlink() shared memory as soon as all processes has opened and mmapped the shared memory. After the shm is unlinked, the shared memory would be cleaned up when the last process die or unmaps the memory area, no need for a supervisor process to clean it up.
    – Lie Ryan
    Jun 11, 2017 at 10:48
  • @Arnold: restarted processes can in theory reuses the previous shared memory if they want to. They can do that by reopening shared memory with the same name. I don't know whether Chrome does this though. POSIX shm can stay around if it's never unlinked even when all the processes that uses it had died.
    – Lie Ryan
    Jun 11, 2017 at 11:33
0

Does this mean that if shared memory segment somehow gets corrupted then the user is basically screwed until they reboot the system?

Almost, but not quite. The user can also unlink the /dev/shm/blah file and kill all processes that uses the shared memory. Alternatively, well written program may detect that the shared memory had become unusable and decide to recreate it.

Or will kernel clear the shared memory by shm_unlink automatically on user logout (without rebooting) after all user processes get killed?

User logout is a userspace concept. The kernel are pretty much unaware about anything related to user logging out, and so it doesn't do anything special when user log out. It's the desktop session manager process that's responsible for clearing user's login session resources when the user has "logged out" (whatever that means), and it's possible that it may be configured to clear all of the user's shm when the user logs out, though I don't know if there are any session manager implementations that actually does this as POSIX shm is usually considered a global resource rather than session resource.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .