Zrzut rdzenia, ale plik rdzenia nie znajduje się w bieżącym katalogu?

Podczas działania programu C mówi „(zrzut pamięci)”, ale nie widzę żadnych plików pod bieżącą ścieżką.

Ustawiłem i zweryfikowałem ulimit:

ulimit -c unlimited 
ulimit -a 

Próbowałem także znaleźć plik o nazwie „core”, ale nie otrzymałem pliku zrzutu pamięci?
Jakaś pomoc, gdzie jest mój podstawowy plik?

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

[/ proc / sys / kernel /] core_pattern służy do określenia nazwy wzorca zrzutu pamięci.

• Jeśli pierwszym znakiem wzorca jest „|”, jądro potraktuje resztę wzorca jako polecenie do uruchomienia. Zrzut rdzenia zostanie zapisany na standardowym wejściu tego programu zamiast do pliku.

Zamiast zapisywać zrzut pamięci na dysk, system jest skonfigurowany do wysyłania go do abrtprogramu. Narzędzie do automatycznego zgłaszania błędów prawdopodobnie nie jest tak udokumentowane, jak powinno ...

W każdym razie szybka odpowiedź jest taka, że ​​powinieneś być w stanie znaleźć swój podstawowy plik, w /var/cache/abrtktórym abrtprzechowuje go po wywołaniu. Podobnie, inne systemy wykorzystujące Apport mogą wpychać rdzenie /var/crashi tak dalej.

Na najnowszym Ubuntu (w moim przypadku 12.04) możliwe jest wydrukowanie „Błąd segmentacji (zrzut rdzenia)”, ale nie powstaje plik rdzenia, w którym można się spodziewać (na przykład dla programu kompilowanego lokalnie).

Może się to zdarzyć, jeśli masz podstawowy rozmiar pliku ulimit 0 (nie zrobiłeś tego ulimit -c unlimited) - jest to domyślny rozmiar w Ubuntu. Zwykle tłumiłoby to „(rdzeń zrzucony)”, wprowadzając cię w błąd, ale w Ubuntu pliki rdzeniowe są przesyłane do Apport (system zgłaszania awarii Ubuntu) przez /proc/sys/kernel/core_pattern, i wydaje się, że powoduje to mylący komunikat.

Jeśli Apport odkryje, że dany program nie jest tym, dla którego powinien zgłaszać awarie (w których się dzieje /var/log/apport.log), wraca do symulacji domyślnego zachowania jądra polegającego na umieszczeniu pliku podstawowego w cwd (odbywa się to w skrypcie /usr/share/apport/apport). Obejmuje to honorowanie ulimit, w którym to przypadku nic nie robi. Ale (zakładam), jeśli chodzi o jądro, został wygenerowany plik rdzenia (i przesłany do apportu), stąd komunikat „Błąd segmentacji (zrzut rdzenia)”.

Ostatecznie PEBKAC za to, że zapomniał ustawić ulimit, ale wprowadzająca w błąd wiadomość sprawiła, że ​​pomyślałem, że oszalałem przez chwilę, zastanawiając się, co zjadło moje pliki core.

(Ogólnie rzecz biorąc, strona podręcznika core (5) - man 5 core- jest dobrym źródłem informacji o tym, gdzie kończy się Twój plik podstawowy i jakie mogą być powody, dla których nie można go zapisać).

Wraz z uruchomieniem systemd pojawia się również inny scenariusz. Domyślnie systemd będzie zapisywał zrzuty rdzenia w swoim dzienniku, które są dostępne za pomocą systemd-coredumpctlpolecenia. Zdefiniowane w pliku core_pattern:

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

To zachowanie można wyłączyć za pomocą prostego „włamania”:

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

Jak zawsze, wielkość zrzutów rdzenia musi być równa lub większa niż wielkość zrzutu rdzenia, jak to zrobiono na przykład ulimit -c unlimited.

Pisanie instrukcji, aby uzyskać zrzut pamięci w Ubuntu 16.04 LTS :

1. Jak wspomniał @jtn w swojej odpowiedzi, Ubuntu deleguje wyświetlanie awarii w celu przypisania , co z kolei odmawia zapisania zrzutu, ponieważ program nie jest zainstalowanym pakietem.

2. Aby rozwiązać ten problem, musimy upewnić się, że apport zapisuje również pliki zrzutu pamięci dla programów innych niż pakiety . Aby to zrobić, utwórz plik o nazwie ~ / .config / apport / settings z następującą zawartością:
   [main] unpackaged=true

3. Teraz ponownie zawiesić program i zobaczyć, jak generowane są pliki awarii w folderze: / var / crash o nazwach takich jak * .1000.crash . Zauważ, że te pliki nie mogą być odczytane bezpośrednio przez gdb .

4. [Opcjonalnie] Aby zrzuty były czytelne przez gdb, uruchom następującą komendę:

   apport-unpack <location_of_report> <target_directory>

Odnośniki: Core_dump - Oracle VM VirtualBox

Mógłbym wymyślić dwie następujące możliwości:

1. Jak już zauważyli inni, program może chdir(). Czy użytkownik uruchamiający program może zapisywać w katalogu, w którym był chdir()edytowany? Jeśli nie, nie może utworzyć zrzutu podstawowego.

2. Z jakiegoś dziwnego powodu zrzut rdzenia nie jest nazwany. core.*Możesz to sprawdzić /proc/sys/kernel/core_pattern. Polecenie find, które podałeś, nie znalazłoby typowego zrzutu pamięci. Powinieneś użyć find / -name "*core.*", jak typowa nazwa rdzeniacore.$PID

Jeśli brakuje podstawowych zrzutów plików binarnych na RHELi podczas korzystania abrt, upewnij się, że/etc/abrt/abrt-action-save-package-data.conf

zawiera

ProcessUnpackaged = yes

Umożliwia to tworzenie raportów o awariach (w tym zrzutów podstawowych) dla plików binarnych, które nie są częścią zainstalowanych pakietów (np. Budowanych lokalnie).

Dla fedora25 mogłem znaleźć plik podstawowy na

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

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

Moje wysiłki w WSL zakończyły się niepowodzeniem.

Dla tych, którzy korzystają z Windows Subsystem for Linux (WSL), wydaje się, że w tej chwili istnieje otwarty problem z brakującymi plikami zrzutu pamięci.

Komentarze wskazują na to

Jest to znany problem, o którym wiemy, że badamy go.

Problem z Githubem

Opinia programisty Windows

W Ubuntu18.04 najłatwiejszym sposobem uzyskania pliku podstawowego jest wprowadzenie poniższej komendy, aby zatrzymać usługę apport.

sudo service apport stop

Następnie uruchom ponownie aplikację, otrzymasz plik zrzutu w bieżącym katalogu.

Jestem na Linux Mint 19 (oparty na Ubuntu 18). Chciałem mieć coredumppliki w bieżącym folderze. Musiałem zrobić dwie rzeczy:

1. Zmień /proc/sys/kernel/core_pattern(przez # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patternlub przez# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
2. Zwiększenie limitu rozmiaru podstawowego pliku o $ ulimit -c unlimited

Zostało to napisane już w odpowiedziach, ale napisałem, by streścić zwięźle. Co ciekawe zmiana limitu nie wymagała uprawnień roota (zgodnie z /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root może tylko obniżyć limit, więc było to nieoczekiwane - komentarze na jego temat są mile widziane).

ulimit -c unlimited sprawiło, że plik rdzenia poprawnie pojawił się w bieżącym katalogu po „zrzutu pamięci”.