Red Hat Training

A Red Hat training course is available for RHEL 8

10.3. Inspeção de estados de colisão de aplicações com lixões de núcleo

Pré-requisitos

  • Você deve ter um arquivo principal de despejo e um relatório do sistema onde ocorreu o acidente.
  • GDB e elfutils devem ser instalados em seu sistema.

Procedimento

  1. Para identificar o arquivo executável onde ocorreu a falha, execute o comando eu-unstrip com o arquivo dump do núcleo:

    $ eu-unstrip -n --core=./core.9814
    0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe]
    0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1
    0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6
    0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2

    A saída contém detalhes para cada módulo em uma linha, separados por espaços. As informações estão listadas nesta ordem:

    1. O endereço de memória onde o módulo foi mapeado
    2. A parte interna do módulo e onde na memória foi encontrado
    3. O nome do arquivo executável do módulo, exibido como - quando desconhecido, ou como . quando o módulo não tiver sido carregado de um arquivo
    4. A fonte de informações de depuração, exibida como um nome de arquivo quando disponível, como . quando contido no próprio arquivo executável, ou como - quando não presente em absoluto
    5. O nome da biblioteca compartilhada (soname) ou [exe] para o módulo principal

    Neste exemplo, os detalhes importantes são o nome do arquivo /usr/bin/sleep e o build-id 2818b2009547f780a5639c904cded443e564973e na linha que contém o texto [exe]. Com estas informações, é possível identificar o arquivo executável necessário para a análise do despejo do núcleo.

  2. Obtenha o arquivo executável que falhou.

    • Se possível, copie-a do sistema onde ocorreu o acidente. Use o nome do arquivo extraído do arquivo principal.
    • Você também pode usar um arquivo executável idêntico em seu sistema. Cada arquivo executável construído no Red Hat Enterprise Linux contém uma nota com um valor de build-id único. Determine o build-id dos arquivos executáveis relevantes disponíveis localmente:

      $ eu-readelf -n executable_file

      Use estas informações para comparar o arquivo executável no sistema remoto com sua cópia local. O build-id do arquivo local e o build-id listado no lixão central devem coincidir.

    • Finalmente, se o aplicativo for instalado a partir de um pacote RPM, você pode obter o arquivo executável a partir do pacote. Use a saída sosreport para encontrar a versão exata do pacote necessário.
  3. Obtenha as bibliotecas compartilhadas utilizadas pelo arquivo executável. Use os mesmos passos que para o arquivo executável.
  4. Se o aplicativo for distribuído como um pacote, carregue o arquivo executável no GDB, para exibir dicas de pacotes de debuginfo em falta. Para mais detalhes, veja Seção 7.4, “Obtendo pacotes de debuginfo para uma aplicação ou biblioteca usando GDB”.
  5. Para examinar o arquivo principal em detalhes, carregue o arquivo executável e o arquivo principal de despejo com a GDB:

    $ gdb -e executable_file -c core_file

    Outras mensagens sobre arquivos ausentes e informações de depuração ajudam a identificar o que está faltando para a sessão de depuração. Retornar à etapa anterior, se necessário.

    Se a informação de depuração da aplicação estiver disponível como um arquivo em vez de um pacote, carregue este arquivo no GDB com o comando symbol-file:

    (gdb) arquivo-símbolo program.debug

    Substituir program.debug pelo nome do arquivo real.

    Nota

    Talvez não seja necessário instalar as informações de depuração para todos os arquivos executáveis contidos no lixão principal. A maioria destes arquivos executáveis são bibliotecas utilizadas pelo código da aplicação. Estas bibliotecas podem não contribuir diretamente para o problema que você está analisando, e você não precisa incluir informações de debugging para eles.

  6. Use os comandos da GDB para inspecionar o estado da aplicação no momento em que ela caiu. Ver Capítulo 8, Aplicação de inspeção do Estado Interno com a GDB.

    Nota

    Ao analisar um arquivo principal, a GDB não é anexada a um processo em execução. Os comandos para controlar a execução não têm efeito.

Recursos adicionais

  • Depuração com GDB
  • Depuração com GDB
  • Depuração com GDB