Ostatnio przechodziłam intensywną instalację programu/pakietu, więc nie mogę stwierdzić, który z nowo zainstalowanych programów (lub starych programów) spowodował pojawienie się pliku core w moim katalogu domowym. To serwer, więc lepiej poznam wszelkie możliwe źródła niestabilności na komputerze.Znajdź program, który spowodował plik zrzutu pamięci głównej
można po prostu użyć programu file do ich identyfikacji:
Np
# file /var/core/core
/var/core/core: ELF 64-bit MSB core file SPARCV9 Version 1, from 'crs_stat.bin'
Czasami miałem podstawowe pliki, które z jakiegoś powodu "plik" nie mogą zidentyfikować - w tych przypadkach może pomóc fakt, że ostatnia linia danych wyjściowych ciągów na pliku core często zawiera ścieżkę do pliku wykonywalnego. na przykład "ciągi/ścieżka/do/plik_końcowy | ogon -n 1" często działa, lub spójrz na kilka ostatnich linii. – jsegal
@jsegal: Dobre znalezisko, ale potrzebowałem 'stringów | grep ^/| tail -1', gdy 'find' powiedział mi:' zbyt wiele sekcji nagłówka programu'. – Tino
można przejść do katalogu, w którym core.pid jest i prowadzony rdzeń gdb core.PID
Często za pomocą programu plików w pliku rdzenia pojawi się błędny plik wykonywalny, jak wyjaśniono przez @Benj w zaakceptowanej odpowiedzi (kod z odpowiedzi Benj):
# file /var/core/core
/var/core/core: ELF 64-bit MSB core file SPARCV9 Version 1, from 'crs_stat.bin'
Jednak czasami może pojawić się zarzut o „zbyt wiele sekcji Nagłówek programu”:
core.some-lib.nnnn.nnnn: ELF 64-bit LSB core file x86-64, version 1 (SYSV), too many program header sections (1850)
W takim przypadku można spróbować alternatywy:
strings core.some-lib.nnnn.nnnn | tail -50gdb -c core.some-lib.nnnn.nnnn to często powiedzieć coś takiego: Core was generated by '/usr/local/bin/some-executable'
W FreeBSD to działa dla mnie, 'dmesg | tail -n 20' – SIFE
@SIFE, który z pewnością zadziała, jeśli stało się to bardzo niedawno. – Benj
@Benj Zapomniałem o tym powiedzieć. – SIFE