Como a corrupção de memória é tratada pelo Linux quando o processo termina?

Question

Há muitas perguntas sobre o estouro de pilha perguntando como um sistema lida com vazamentos de memória e o que acontece em términos anormais. Exemplos:

link

link

link

No entanto, não encontrei nenhuma postagem perguntando o mesmo sobre a corrupção de memória. O manuseio de vazamentos de memória e corrupção de memória pelo kernel do Linux é o mesmo? Quando o processo termina, os segmentos corrompidos da memória são liberados e recuperados, e eles são seguros para uso por outros processos?

Além disso, e os processos que usam memória compartilhada POSIX (/ dev / shm)? Pelo que entendi, parece que a memória compartilhada não é recuperada pelo sistema, a menos que seja excluída pelo shm_unlink. ( link ) Isso significa que, se o segmento de memória compartilhada de alguma forma for corrompido, o usuário será basicamente parafusado até que ele reinicie o sistema? Ou o kernel limpará a memória compartilhada por shm_unlink automaticamente no logout do usuário (sem reinicializar) depois que todos os processos do usuário forem mortos?

Obrigado!

    

Answer 1

Quando um processo morre, sua memória é recuperada pelo sistema operacional. É marcado como livre e será alocado para outros processos, mais cedo ou mais tarde, quando outros processos precisarem de memória. A memória é sempre apagada antes de ser alocada para um processo.

Não importa que tenha havido corrupção de memória no processo. O conceito de corrupção de memória está no contexto da execução do processo - significa que o conteúdo da memória não é o que o programador pretendia. Quando o processo está morto, esse conceito não é mais significativo. O mesmo vale para um vazamento de memória: toda a memória do processo é recuperada quando sai.

A memória compartilhada é uma exceção, porque não pertence a nenhum processo único. Quando um processo sai, tudo o que é recuperado é o identificador do processo na memória compartilhada; a memória compartilhada permanece até que seja explicitamente removida. Pense em um objeto de memória compartilhada como um arquivo que vive exclusivamente na memória e não está conectado ao sistema de arquivos. É como um arquivo temporário sem nome.

Um processo que usa memória compartilhada deve limpá-lo antes de sair. De preferência, se um processo usa memória compartilhada, ele deve ser executado por um processo de supervisor, e o supervisor deve limpar recursos, como memória compartilhada e arquivos temporários, se o processo principal falhar.

    

Answer 2

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

Quase, mas não completamente. O usuário também pode desvincular o arquivo / dev / shm / blah e eliminar todos os processos que usam a memória compartilhada. Alternativamente, um programa bem escrito pode detectar que a memória compartilhada se tornou inutilizável e decide recriá-la.

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

O logout de usuário é um conceito de espaço do usuário. O kernel praticamente não tem conhecimento de nada relacionado ao logout do usuário, e por isso não faz nada de especial quando o usuário efetua logout. É o processo do gerenciador de sessão de desktop que é responsável por limpar os recursos da sessão de login do usuário quando o usuário "desconectou" (o que quer que isso signifique), e é possível que ele seja configurado para limpar todo o usuário quando ele efetua logout. Não sei se existem implementações de gerenciadores de sessão que realmente fazem isso, já que POSIX shm é geralmente considerado um recurso global em vez de um recurso de sessão.