O sinal de segfault é sempre enviado para o aplicativo

Question

Meu aplicativo geralmente trava e imprime a pilha para registrar se o sinal de segfault recebido.

Mas em alguns ambientes, o 'dmesg' mostra mensagens de segfault relacionadas ao meu aplicativo, mas o tempo de atividade do aplicativo é muito mais antigo.

O segfault pode ser suprimido e o aplicativo não recebe sinal? Ou quais erros do dmesg podem significar?

    

Answer 1

É possível para uma aplicação ou ignorar ou fazer algum tratamento especial para o sinal de falha de segmentação. A página de manual para páginas de sinal e relacionadas tem detalhes sobre isso.

Uma possível situação que vejo pode levar ao comportamento descrito (o dmesg reporta os segfaults, mas o aplicativo está em execução) é que o aplicativo é forjado e o processo filho segfaults. Para saber se esse é o caso, verifique se o ID do processo relatado pelo dmesg é o mesmo que o processo em execução no momento.

    

Answer 2

Os programas executados em segundo plano podem fazer bom uso do tratamento de um SIGSEGV, apenas para registrar o fato de que isso aconteceu junto com o contexto antes de sair. Isso fornece não apenas uma indicação do que deu errado em um arquivo de log, mas também informações úteis para incluir em um relatório de bug. Sim, o sinal pode ser ignorado, mas isso é somente através de ação deliberada e quase sempre é uma má ideia (a menos que você esteja testando em um kernel experimental com um subsistema vmm com bugs conhecidos).

Infelizmente, uma vez que o sinal é capturado, QUALQUER COISA é suspeita. Por exemplo, usar qualquer coisa que aloque memória no manipulador SEGV é muito provavelmente uma má idéia. O mesmo vale para funções variadicas como printf (). Então, sim, enquanto um aplicativo está lidando com o sinal, ele pode não estar fazendo isso de forma eficaz, por isso você só vê vestígios dele no dmesg.

De qualquer forma, sim, o sinal é enviado para a aplicação, no entanto SEGV não é um sinal em tempo real e pode ser mesclado pelo kernel. Ou seja, se um programa acessa a memória, ele não tem permissão para acessar 15 vezes, há uma boa chance de que apenas um SEGV seja realmente entregue, dependendo do tempo de acesso à memória ilegal.

Em manipuladores SEGV, open () write () e close () são seus amigos e usam um registro de depuração especial (por exemplo, um fluxo FILE de registro que pode ter sido aberto anteriormente).

    

Answer 3

SIGSEGV é enviado automaticamente pelo kernel se um processo faz algo com a memória que não deveria ter feito; mas o sinal pode ser capturado e o processo pode executar um manipulador de sinal, que pode tentar recuperar-se da condição de falha. Nesse caso, o processo pode continuar em execução.

O sinal também pode ser completamente ignorado, mas isso é algo que deve ser evitado; obter um SIGSEGV geralmente significa que há algo muito, muito errado acontecendo.

    

Answer 4

Falha de segmentação geralmente significa que algo correu muito mal com o estado interno do aplicativo. Ele pode estar tão quebrado, que não é capaz de executar o manipulador de sinal - o manipulador de sinal, que deve imprimir o despejo de pilha, pode falhar também.

Edit: Eu não entendi muito bem a parte 'uptime older', então eu pulei. Como agora vejo que a sua pergunta era "por que o aplicativo ainda está em execução", aqui está a nova resposta:

Sim, o aplicativo pode sobreviver a um SIGSEGV. Às vezes, o SIGSEGV será enviado apenas para algum segmento menos importante (ele deve matar o aplicativo inteiro, mas às vezes não é) ou até mesmo apenas um processo filho - o que você vê como um aplicativo pode ser vários processos ou threads.