Núcleo despejado, mas o arquivo principal não está no diretório atual?

277

Durante a execução de um programa C, ele diz "(core dumped)", mas não consigo ver nenhum arquivo no caminho atual.

Eu configurei e verifiquei o ulimit:

ulimit -c unlimited 
ulimit -a

Eu também tentei encontrar um arquivo chamado "core", mas não recebi o arquivo despejado do núcleo?
Qualquer ajuda, onde está o meu arquivo principal?

c  linux  coredump 
— webminal.org
fonte
1
O programa chama chdir em algum momento? Se sim, olhe lá.
— William Pursell
2
O programa altera seu diretório de trabalho? Olhe ali.
— Richard Pennington
Gostaria de pesquisar todo o disco rígido para um arquivo recente;)
— Hamish Grubijan
1
opa não, não está lá ... eu verifiquei .. programa chdir para / mnt e / i verifiquei os dois diretórios, mas não consegui encontrar o arquivo. Eu até encontrei / -name "* core". mesmo isso não me mostrou o arquivo. O programa usa C + sqlite, enquanto insere valores que despeja o núcleo. Diz erro de asserção == 0 pela primeira vez e erro = 101 pela segunda vez ..
— webminal.org
8
Sim, se você substituir /proc/sys/kernel/core_patternpor uma sequência iniciada por /tmp, é para onde os seus despejos principais irão.
— ephemient

Respostas:

240

Leia /usr/src/linux/Documentation/sysctl/kernel.txt .

[/ proc / sys / kernel /] core_pattern é usado para especificar um nome de padrão de arquivo de despejo principal.

  • Se o primeiro caractere do padrão for um '|', o kernel tratará o restante do padrão como um comando a ser executado. O dump principal será gravado na entrada padrão desse programa em vez de em um arquivo.

Em vez de gravar o dump principal em disco, seu sistema está configurado para enviá-lo ao abrtprograma. A Ferramenta Automatizada de Relatório de Erros possivelmente não está tão documentada quanto deveria ...

De qualquer forma, a resposta rápida é que você poderá encontrar seu arquivo principal /var/cache/abrt, onde o abrtarmazena após ser chamado. Da mesma forma, outros sistemas que usam o Apport podem desviar os núcleos /var/crashe assim por diante.

— efémero
fonte
30
sim, editei core_pattern com o seguinte conteúdo echo "core.% e.% p"> / proc / sys / kernel / core_pattern .. agora ele cria o arquivo de despejo central no próprio diretório atual. com o nome "core.giis.12344" etc. Obrigado a todos por suas respostas / comentários / dicas.
— webminal.org 15/01/10
20
Apenas a nota que o Fedora 18 ABRT programa está armazenando descarregar um core em /var/spool/abrt/vez de/var/cache/abrt
— Nelson
4
Existe uma maneira de permitir que os usuários configurem isso por si mesmos, em vez de todos terem que usar a configuração do sistema?
— Allyourcode 17/10/2013
Quando esse comando é executado e o processo é chamado, stdout e stderr não são abertos por padrão? Eu vejo coisas muito estranhas acontecendo. Quando eu uso dup2 do stderr e stdout no meu arquivo personalizado (applog.txt), os dados que estou gravando em outro arquivo (mycore.BIN) estão sendo redirecionados para o arquivo que eu usei para capturar o stdout & stderr (applog.txt) . Existe uma boa leitura sobre este? Por favor sugira. Obrigado
— mk ..
20
systemd no archlinux store coredumps em #/var/lib/systemd/coredump/
— Francois
224

No Ubuntu recente (12.04 no meu caso), é possível que "Falha de segmentação (core despejado)" seja impressa, mas nenhum arquivo principal foi produzido onde você poderia esperar um (por exemplo, para um programa compilado localmente).

Isso pode acontecer se você tiver um ulimit de tamanho de arquivo principal igual a 0 (ainda não o fez ulimit -c unlimited) - esse é o padrão no Ubuntu. Normalmente, isso suprimiria o "(núcleo despejado)", enganando você, mas no Ubuntu, os corefiles são canalizados para o Apport (sistema de relatório de falhas do Ubuntu) via /proc/sys/kernel/core_pattern, e isso parece causar a mensagem enganosa.

Se o Apport descobrir que o programa em questão não é um para o qual deveria estar relatando falhas (o que você pode ver acontecendo /var/log/apport.log), ele volta a simular o comportamento padrão do kernel de colocar um arquivo principal no cwd (isso é feito no script /usr/share/apport/apport) Isso inclui honrar o ulimit, caso em que não faz nada. Mas (eu assumo) no que diz respeito ao kernel, um corefile foi gerado (e canalizado para apport), daí a mensagem "Falha na segmentação (core despejado)".

Por fim, PEBKAC por esquecer de definir ulimit, mas a mensagem enganosa me fez pensar que eu estava ficando louco por um tempo, imaginando o que estava comendo meus arquivos principais.

(Além disso, em geral, a página de manual do núcleo (5) - man 5 core- é uma boa referência para onde seu arquivo principal termina e os motivos pelos quais ele pode não ser gravado.)

— jtn
fonte
4
Muito obrigado - encontrei o mesmo problema. Aliás, o Ubuntu 14.04 exibe exatamente o mesmo comportamento que você descreveu.
— Malte Skoruppa
5
Na minha instalação do Ubuntu (modificada 14.04), há uma solução temporária fácil para isso executando sudo service apport stop--- depois que eu executei, ele mudou /proc/sys/kernel/core_patterndo apport pipe para apenas core. O Apport é inteligente o suficiente para consertar core_patterntemporariamente, suponho.
— Patrick Collins
6
"ulimit -c unlimited" é exatamente o que eu precisava - Obrigado!
— Dave C
4
Eu tentei cada resposta aplicável, e cada localização em cada comentário aqui depois de fazer o comando ulimit, mas ainda não conseguiu encontrar um lugar arquivo core no meu Ubuntu 16.04 LTS ...
— Nagev
2
@ElectricGoat Não, eu não tenho. É um design pobre de UX, IMO. O sistema deve apenas imprimir o caminho ou não imprimir uma mensagem se não estiver sendo criado. Vou adicionar minha própria resposta, quando ou se tiver a chance de investigar isso mais a fundo.
— Nagev 17/08/19
80

Com o lançamento do systemd , há outro cenário também. Por padrão, o systemd armazenará os dumps principais em seu diário, sendo acessível com o systemd-coredumpctlcomando Definido no arquivo core_pattern:

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Esse comportamento pode ser desabilitado com um simples "hack":

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

Como sempre, o tamanho dos dumps do núcleo deve ser igual ou superior ao tamanho do núcleo que está sendo despejado, como feito por exemplo ulimit -c unlimited.

— timss
fonte
Esse "hack" não funcionou para mim (mesmo após uma reinicialização). Estou executando o Arch Linux e já executei ulimit -c unlimited.
— gsingh2011
@ gsingh2011 Pode estar desatualizado. Eu não corro mais o Arch, então não posso dizer se deve funcionar nos dias de hoje. Se você descobrir, sinta-se à vontade para me atualizar com um novo comentário.
— TIMSS
5
@ gsingh2011 Tente em 50-coredump.confvez de coredump.conf. Isso deve substituir /lib/sysctl.d/50-coredump.conf. O padrão pode ser restaurado comsysctl -w kernel.core_pattern=core
— Lekensteyn
Eu tive que desligar appport para que isso funcionesudo service apport stop
— rahul003
51

Escrevendo instruções para obter um dump principal no Ubuntu 16.04 LTS :

  1. Como o @jtn mencionou em sua resposta, o Ubuntu delega a exibição de falhas para apport , que por sua vez se recusa a escrever o dump porque o programa não é um pacote instalado.Antes de fazer alterações

  2. Para solucionar o problema, precisamos garantir que o apport grave também os arquivos de despejo principal para programas que não sejam de pacote . Para fazer isso, crie um arquivo chamado ~ / .config / apport / settings com o seguinte conteúdo:
    [main] unpackaged=true

  3. Agora trava seu programa novamente e vê seus arquivos travados serem gerados na pasta: / var / crash com nomes como * .1000.crash . Observe que esses arquivos não podem ser lidos diretamente pelo gdb .Depois de fazer alterações

  4. [Opcional] Para tornar os dumps legíveis pelo gdb, execute o seguinte comando:

    apport-unpack <location_of_report> <target_directory>

Referências: Core_dump - Oracle VM VirtualBox

— ankurrc
fonte
3
Esta é a única solução que funcionou para mim no Ubuntu 18.04 #
— greuze
Qual usuário ~ pertence? Se o processo for executado pela raiz, isso significa /root/.config/apport/settings?
— 27619 Nicholi
@ Nicoli Eu acredito que deveria ser o usuário que executou o programa. Eu não tenho certeza.
— ankurrc
12

Eu poderia pensar em duas seguintes possibilidades:

  1. Como outros já apontaram, o programa pode chdir(). O usuário que está executando o programa pode gravar no diretório em que chdir()está? Caso contrário, não poderá criar o dump principal.

  2. Por algum motivo estranho, o dump principal não é nomeado. core.*Você pode verificar /proc/sys/kernel/core_patternisso. Além disso, o comando find que você nomeou não encontrou um dump principal típico. Você deve usar find / -name "*core.*", pois o nome típico do coredump écore.$PID

— ahans
fonte
aqui está o meu padrão - isso significa que o arquivo principal é chamado algo como "PID.signal.userid" em vez de core.pid ??? $ cat / proc / sys / kernel / core_pattern / usr / lib / hookCCpp / var / char / abrt% p% s% u
— webminal.org
9

Se você estiver perdendo os core dumps para binários no RHELe ao usar abrt, verifique se/etc/abrt/abrt-action-save-package-data.conf

contém 

ProcessUnpackaged = yes

Isso permite a criação de relatórios de falhas (incluindo dumps principais) para binários que não fazem parte dos pacotes instalados (por exemplo, compilados localmente).

— MRalwasser
fonte
6

Para o fedora25, eu poderia encontrar o arquivo principal em 

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

onde ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %conforme `/ proc / sys / kernel / core_pattern '

— desfiladeiro
fonte
5

No Ubuntu18.04, a maneira mais fácil de obter um arquivo principal é inserir o comando abaixo para interromper o serviço apport.

sudo service apport stop

Em seguida, execute novamente o aplicativo, você obterá o arquivo de despejo no diretório atual.

— Nicolas Gong
fonte
3

Estou no Linux Mint 19 (baseado no Ubuntu 18). Eu queria ter coredumparquivos na pasta atual. Eu tive que fazer duas coisas:

  1. Mudança /proc/sys/kernel/core_pattern(por # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patternou por# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
  2. Aumentando o limite para o tamanho do arquivo principal em $ ulimit -c unlimited

Isso já foi escrito nas respostas, mas escrevi para resumir sucintamente. Curiosamente, o limite de alteração não exigia privilégios de root (como em /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-nonnonroot-user non- root só pode diminuir o limite, o que foi inesperado - comentários sobre isso são bem-vindos).

— Marisha
fonte
2

ulimit -c unlimited fez com que o arquivo principal apareça corretamente no diretório atual após um "núcleo despejado".

— Nicolas VERHELST
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.