Core dibuang, tetapi file inti tidak ada di direktori saat ini?

277

Saat menjalankan program C, Dikatakan "(core dumped)" tapi saya tidak bisa melihat file di bawah jalur saat ini.

Saya telah menetapkan dan memverifikasi ulimit:

ulimit -c unlimited 
ulimit -a

Saya juga mencoba menemukan file bernama "core", tetapi tidak mendapatkan file inti yang dibuang?
Ada bantuan, di mana file inti saya?

c linux coredump

— webminal.org
sumber

1

Apakah program memanggil chdir di beberapa titik? Jika demikian, lihat di sana.

— William Pursell

2

Apakah program mengubah direktori kerjanya? Lihat disana.

— Richard Pennington

Saya akan mencari seluruh hard drive untuk file terbaru;)

— Hamish Grubijan

1

oops tidak ada tidak ada di sana ... saya memeriksanya ..program chdir ke / mnt dan / saya memeriksa kedua direktori tetapi tidak dapat menemukan file. Saya bahkan menemukan / -nama "* core." bahkan ini tidak menunjukkan file kepada saya. Program ini menggunakan C + sqlite, sementara memasukkan nilai-nilai itu inti dumps. Itu mengatakan kesalahan pernyataan == 0 untuk pertama kalinya dan kesalahan = 101 untuk kedua kalinya ..

— webminal.org

8

Ya, jika Anda mengganti /proc/sys/kernel/core_patterndengan string yang dimulai dengan /tmpmaka di situlah inti dump Anda akan pergi.

— ephemient

240

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

[/ proc / sys / kernel /] core_pattern digunakan untuk menentukan nama pola inti dumpfile.

Jika karakter pertama pola adalah '|', kernel akan memperlakukan sisa pola sebagai perintah untuk dijalankan. Inti dump akan ditulis ke input standar dari program itu, bukan ke file.

Alih-alih menulis dump inti ke disk, sistem Anda dikonfigurasi untuk mengirimkannya ke abrtprogram. Alat Pelaporan Bug Otomatis mungkin tidak terdokumentasi seperti seharusnya ...

Bagaimanapun, jawaban cepatnya adalah Anda harus dapat menemukan file inti Anda /var/cache/abrt, tempat abrtmenyimpannya setelah dipanggil. Demikian pula, sistem lain yang menggunakan Apport dapat menyemprotkan inti /var/crash, dan sebagainya.

— singkat
sumber

30

ya, saya telah mengedit core_pattern dengan mengikuti gema konten "core.% e.% p"> / proc / sys / kernel / core_pattern ..sekarang ia membuat file dump inti di direktori saat ini. dengan nama "core.giis.12344" dll. Terima kasih atas jawaban / komentar / petunjuk Anda.

— webminal.org

20

Hanya untuk catatan bahwa fedora 18 ABRT program menyimpan kesedihan inti dalam /var/spool/abrt/bukannya/var/cache/abrt

— Nelson

4

Apakah ada cara untuk memungkinkan pengguna untuk mengkonfigurasi ini untuk diri mereka sendiri, daripada semua orang harus menggunakan konfigurasi sistem?

— allyourcode

Ketika perintah ini dijalankan dan proses dipanggil, apakah stdout dan stderr tidak dibuka secara default? Saya melihat hal-hal aneh terjadi. ketika saya menggunakan dup2 stderr dan stdout ke file kustom saya (applog.txt), data yang saya tulis ke file lain (mycore.BIN) sedang diarahkan ke file yang saya gunakan untuk menangkap stdout & stderr (applog.txt) . Apakah ada bacaan yang bagus tentang yang ini? Tolong sarankan. Terima kasih

— mk ..

20

systemd di archlinux store coredumps in/var/lib/systemd/coredump/

— Francois

224

Pada Ubuntu baru-baru ini (12,04 dalam kasus saya), dimungkinkan untuk "Segmentasi fault (core dumped)" untuk dicetak, tetapi tidak ada file inti yang dihasilkan di mana Anda mungkin mengharapkan satu (misalnya untuk program yang dikompilasi secara lokal).

Ini dapat terjadi jika Anda memiliki ukuran file inti ulimit 0 (Anda belum melakukannya ulimit -c unlimited) - ini adalah default pada Ubuntu. Biasanya itu akan menekan "(core dumped)", membuat Anda salah, tetapi di Ubuntu, corefiles disalurkan ke Apport (sistem pelaporan kerusakan Ubuntu) via /proc/sys/kernel/core_pattern, dan ini tampaknya menyebabkan pesan yang menyesatkan.

Jika Apport menemukan bahwa program yang dimaksud bukan program yang seharusnya dilaporkan macet (yang dapat Anda lihat terjadi /var/log/apport.log), program kembali ke simulasi perilaku kernel default dengan meletakkan file inti di cwd (ini dilakukan dalam skrip /usr/share/apport/apport). Ini termasuk menghormati ulimit, dalam hal ini tidak melakukan apa-apa. Tapi (saya berasumsi) sejauh menyangkut kernel, corefile dihasilkan (dan disalurkan ke apport), maka pesan "Segmentasi fault (core dumped)".

Pada akhirnya PEBKAC karena lupa mengatur ulimit, tetapi pesan yang menyesatkan membuat saya berpikir saya akan menjadi gila untuk sementara waktu, bertanya-tanya apa yang memakan corefiles saya.

(Juga, secara umum, halaman manual inti (5) - man 5 core- adalah referensi yang bagus untuk tempat file inti Anda dan alasan mengapa itu tidak dapat ditulis.)

— jtn
sumber

4

Terima kasih banyak - saya mengalami masalah yang sama. Btw, Ubuntu 14.04 menunjukkan perilaku yang persis sama dengan yang Anda jelaskan.

— Malte Skoruppa

5

Pada instalasi Ubuntu saya (dimodifikasi 14.04), ada solusi sementara yang mudah untuk ini dengan menjalankan sudo service apport stop--- setelah saya jalankan itu, itu berubah /proc/sys/kernel/core_patterndari pipa apport menjadi adil core. Apport cukup pintar untuk memperbaiki core_patternsementara, saya kira.

— Patrick Collins

6

"ulimit -c unlimited" adalah yang saya butuhkan - Terima kasih!

— Dave C

4

Saya telah mencoba setiap jawaban yang berlaku, dan setiap lokasi di setiap komentar di sini setelah melakukan perintah ulimit, tetapi masih tidak dapat menemukan file inti di mana pun di Ubuntu 16.04 LTS saya ...

— Nagev

2

@ElectricGoat Tidak, belum. Ini desain UX yang buruk, IMO. Sistem seharusnya hanya mencetak jalur, atau tidak mencetak pesan sama sekali jika itu tidak dibuat. Saya akan menambahkan jawaban saya sendiri, kapan atau jika saya mendapat kesempatan untuk menyelidiki ini lebih lanjut.

— Nagev

80

Dengan peluncuran systemd , ada skenario lain juga. Secara default systemd akan menyimpan dump inti dalam jurnal-nya, dapat diakses dengan systemd-coredumpctlperintah. Didefinisikan di file core_pattern:

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

Perilaku ini dapat dinonaktifkan dengan "retasan" sederhana:

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

Seperti biasa, ukuran core dumps harus sama atau lebih tinggi dari ukuran core yang sedang dibuang, seperti yang dilakukan oleh misalnya ulimit -c unlimited.

— timss
sumber

"Retasan" itu tidak berhasil untuk saya (bahkan setelah restart). Saya menjalankan Arch Linux dan saya sudah menjalankan ulimit -c unlimited.

— gsingh2011

@ gsingh2011 Mungkin sudah ketinggalan zaman. Saya tidak menjalankan Arch lagi jadi saya tidak bisa mengatakan apakah itu akan berfungsi hari ini. Jika Anda mengetahuinya, silakan memperbarui saya / kami dengan komentar baru.

— timss

5

@ gsingh2011 Coba 50-coredump.confalih-alih coredump.conf. Ini harus diganti /lib/sysctl.d/50-coredump.conf. Default dapat dipulihkan dengansysctl -w kernel.core_pattern=core

— Lekensteyn

Saya harus mematikan aplikasi agar ini berfungsisudo service apport stop

— rahul003

51

Instruksi penulisan untuk mendapatkan dump inti di bawah Ubuntu 16.04 LTS :

Seperti @jtn telah disebutkan dalam jawabannya, Ubuntu mendelegasikan tampilan crash ke apport , yang pada gilirannya menolak untuk menulis dump karena program ini bukan paket yang diinstal.
Untuk mengatasi masalah ini, kita perlu memastikan bahwa apport juga menulis file dump inti untuk program non-paket . Untuk melakukannya, buat file bernama ~ / .config / apport / settings dengan konten berikut:
[main] unpackaged=true
Sekarang crash lagi program Anda, dan lihat file macet Anda dibuat di dalam folder: / var / crash dengan nama seperti * .1000.crash . Perhatikan bahwa file-file ini tidak dapat dibaca oleh gdb secara langsung.
[Opsional] Agar dumps dapat dibaca oleh gdb, jalankan perintah berikut:

apport-unpack <location_of_report> <target_directory>

Referensi: Core_dump - Oracle VM VirtualBox

— pergelangan kaki
sumber

3

Ini adalah satu-satunya solusi yang bekerja untuk saya di Ubuntu 18.04

— selesai

Pengguna yang mana ~ / berkaitan dengan? Jika proses dijalankan oleh root, apakah itu berarti /root/.config/apport/settings?

— Nicholi

@Nicholi, saya percaya seharusnya pengguna yang menjalankan program. Tapi saya tidak yakin.

— ankurrc

12

Saya bisa memikirkan dua kemungkinan berikut:

Seperti orang lain sudah tunjukkan, programnya mungkin chdir(). Apakah pengguna yang menjalankan program diizinkan untuk menulis ke dalam direktori yang menjadi chdir()tujuannya? Jika tidak, itu tidak dapat membuat dump inti.
Untuk beberapa alasan aneh, dump inti tidak bernama core.*Anda dapat memeriksa /proc/sys/kernel/core_patternitu. Juga, perintah find yang Anda beri nama tidak akan menemukan dump inti khas. Anda harus menggunakan find / -name "*core.*", karena nama khas dari coredump adalahcore.$PID

— ahans
sumber

di sini adalah pola saya - apakah ini berarti file inti bernama sesuatu seperti "PID.signal.userid" bukan core.pid ??? $ cat / proc / sys / kernel / core_pattern / usr / lib / hookCCpp / var / char / abrt% p% s% u

— webminal.org

9

Jika Anda kehilangan core dump untuk binari RHELdan saat menggunakan abrt, pastikan itu/etc/abrt/abrt-action-save-package-data.conf

mengandung

ProcessUnpackaged = yes

Ini memungkinkan pembuatan laporan kerusakan (termasuk dump inti) untuk binari yang bukan bagian dari paket yang diinstal (misalnya dibuat secara lokal).

— MRalwasser
sumber

6

Untuk fedora25, saya dapat menemukan file inti di

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

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

— darave mahaveer
sumber

5

Upaya saya di WSL tidak berhasil.

Bagi mereka yang menjalankan Windows Subsystem untuk Linux (WSL) tampaknya ada masalah terbuka saat ini untuk file core dump yang hilang.

Komentar menunjukkan itu

Ini adalah masalah yang diketahui yang kita sadari, itu adalah sesuatu yang sedang kita selidiki.

Masalah Github

Umpan Balik Pengembang Windows

— Brandon Søren Culley
sumber

5

Di Ubuntu18.04, cara paling mudah untuk mendapatkan file inti adalah dengan memasukkan perintah di bawah ini untuk menghentikan layanan apport.

sudo service apport stop

Kemudian jalankan kembali aplikasi, Anda akan mendapatkan file dump di direktori saat ini.

— Nicolas Gong
sumber

3

Saya menggunakan Linux Mint 19 (berbasis Ubuntu 18). Saya ingin memiliki coredumpfile di folder saat ini. Saya harus melakukan dua hal:

Ubah /proc/sys/kernel/core_pattern(oleh # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patternatau oleh# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
Meningkatkan batas untuk ukuran file inti dengan $ ulimit -c unlimited

Itu sudah tertulis dalam jawaban, tetapi saya menulis untuk meringkas secara ringkas. Batas perubahan yang menarik tidak memerlukan hak akses root (sesuai /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root hanya dapat menurunkan batas, jadi itu tidak terduga - komentar tentangnya diterima).

— Marisha
sumber

2

ulimit -c unlimited membuat file inti muncul dengan benar di direktori saat ini setelah "core dumped".

— Nicolas VERHELST
sumber