Como visualizar o arquivo principal (geral)

Question

Cenário (Ubuntu 16.04):

Eu compilo e executo um programa em C (com -g , eu obtenho o tradicional Segmentation Fault (core dumped) , e então (é claro) não há nenhum arquivo "núcleo" mítico a ser encontrado. Algumas pesquisas dizem para modificar /proc/sys/kernel/core_pattern com um comando para o efeito de: echo '|tee /home/me/my_core_folder/my_core_file' | sudo tee /proc/sys/kernel/core_pattern , e depois de fazer isso, eu paro de receber (core dumped) e começo apenas recebendo o Segmentation Fault normal. Eu tento coisas como gdb ./program_object_file.out core.pid que obviamente não existe desesperada), e claro, tente o gdb ./a.out simples seguido por (gdb) core core.pid e variantes dos comandos onde eu spam a tecla tab tentando desesperadamente obter auto-completar para me levar até onde eu preciso estar.

Pergunta:

Existe uma maneira generalizada de obter dumps principais? Eu reconheço que cada máquina que eu toco parece ter uma capacidade de Transformadores de Michael Bay para reconfigurar hardware e software de modo que nenhum dispositivo que possuo possa funcionar normalmente pronto para uso ( Eu tenho a pior sorte com esse tipo de coisa), mas isso está me deixando louca. Existe um algoritmo / receita simples que eu possa seguir para localizar os core dumps na minha própria máquina, assim como nas máquinas de outras pessoas? Eu sempre me encontro ajudando meus amigos em coisas como essa depois de uma pequena quantidade de trabalho (tortura?) Para fazer as coisas funcionarem para mim e seria legal poder rodar um comando ou algo assim para obter os arquivos principais despejados no diretório que o executável foi executado de ... existe alguma maneira de fazer isso que deve funcionar na maioria (eu iria resolver para "alguns") máquinas Linux / Unix?

    

Answer 1

A core(5) página descreve detalhadamente os parâmetros que afetam os despejos principais, incluindo sua nomeação, etc.

Para responder à sua pergunta, não há uma maneira generável de encontrar um dump principal. Por padrão, o core é despejado no diretório de trabalho atual do processo , se o processo tiver permissão para gravar lá, se houver espaço suficiente no sistema de arquivos que o contém, se não houver nenhum dump principal (sob algumas circunstâncias ), e se o tamanho do arquivo e os limites do tamanho do arquivo principal (conforme definido por ulimit ou mecanismos semelhantes) permitirem isso. Mas o /proc/sys/kernel/core_pattern fornece muitas maneiras diferentes de processar os core dumps, então você também precisa ver isso e descobrir o que está acontecendo.

No seu caso, não sei por que o núcleo não pôde ser encontrado inicialmente, mas sei por que você parou de obter núcleos depois de configurar o redirecionamento: ao usar um canal em core_pattern , o programa de processamento < em> must ser especificado usando um nome de caminho absoluto. tee por conta própria não será usado; você precisa especificar /usr/bin/tee . Observe que você deve tomar cuidado especial com esse tipo de configuração em sistemas multiusuário, porque o programa executado para processar o dump principal é executado como root .

Nos derivados do Debian eu instale corekeeper , que grava os core dumps de uma maneira facilmente utilizável por usuário diretórios sob /var/crash .

    

Answer 2

(Movendo uma resposta do OP na questão para uma resposta)

Marquei a resposta abaixo como a resposta correta, já que ela me ajudou a identificar o que realmente estava dando errado, e gostaria de voltar no futuro para detalhar isso um pouco mais, mas minha solução atual (que eu suspeito que seria trabalho na maioria das máquinas Linux) é usar os seguintes comandos-

cat /proc/sys/kernel/core_pattern > ~/.core_pattern.bak 
echo '|/usr/bin/tee ~/path_you_wish_to_dump_to/core/dump' | sudo tee /proc/sys/kernel/core_pattern

Isso fará o backup de seu método de despejo principal anterior em um arquivo oculto ( .core_pattern.bak ) em sua pasta pessoal, que pode ser restaurada com

sudo cp ~/.core_pattern.bak /proc/sys/kernel/core_pattern

e o segundo comando fará com que os core dumps sejam despejados em uma pasta chamada core como um arquivo chamado dump . Obviamente, você pode mexer com este formato para obter um padrão mais ao seu gosto. Deve-se notar, no entanto, que, até onde eu sei, isso irá armazenar apenas um core dump de cada vez (cada um novo irá destruir os antigos), mas se eu pessoalmente verificar um core dump, é para o programa que acabou de rodar, e desde que eu não tenho necessidade de manter lixões antigos, esta é uma boa solução para mim e para a maioria dos aplicativos que meus amigos estarão criando e depurando. Eu adoraria modificar essa resposta um pouco mais no caminho para incluir coisas como o PID que causou o segfault (principalmente apenas açúcar no topo, uma vez que - novamente - eu normalmente sei qual programa causou o segfault, já que eu corri) certamente será suficiente para mim e para muitas pessoas que eu imagino.

Por último, mas não menos importante, para ver o despejo, basta executar o comando:

gdb ./executable_that_crashed ~/path_you_wish_to_dump_to/core/dump

Supondo que você esteja na pasta onde você compilou / executou o executável que está obtendo o segfault.