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?
/proc/sys/kernel/core_pattern
ciąg rozpoczynający się od/tmp
, to tam pójdą twoje zrzuty pamięci.Odpowiedzi:
Przeczytaj /usr/src/linux/Documentation/sysctl/kernel.txt .
Zamiast zapisywać zrzut pamięci na dysk, system jest skonfigurowany do wysyłania go do
abrt
programu. 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/abrt
którymabrt
przechowuje go po wywołaniu. Podobnie, inne systemy wykorzystujące Apport mogą wpychać rdzenie/var/crash
i tak dalej.źródło
/var/spool/abrt/
zamiast/var/cache/abrt
/var/lib/systemd/coredump/
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ć).źródło
sudo service apport stop
--- po uruchomieniu zmieniłem/proc/sys/kernel/core_pattern
z potoku apport na justcore
. Przypuszczam, że Apport jest na tyle sprytny, by naprawićcore_pattern
tymczasowo.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-coredumpctl
polecenia. Zdefiniowane w pliku core_pattern:To zachowanie można wyłączyć za pomocą prostego „włamania”:
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
.źródło
ulimit -c unlimited
.50-coredump.conf
zamiastcoredump.conf
. To powinno zastąpić/lib/sysctl.d/50-coredump.conf
. Domyślne ustawienie można przywrócić za pomocąsysctl -w kernel.core_pattern=core
sudo service apport stop
Pisanie instrukcji, aby uzyskać zrzut pamięci w Ubuntu 16.04 LTS :
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.
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
[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
źródło
Mógłbym wymyślić dwie następujące możliwości:
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.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
źródło
Jeśli brakuje podstawowych zrzutów plików binarnych na
RHEL
i podczas korzystaniaabrt
, upewnij się, że/etc/abrt/abrt-action-save-package-data.conf
zawiera
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).
źródło
Dla fedora25 mogłem znaleźć plik podstawowy na
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 'źródło
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
Problem z Githubem
Opinia programisty Windows
źródło
W Ubuntu18.04 najłatwiejszym sposobem uzyskania pliku podstawowego jest wprowadzenie poniższej komendy, aby zatrzymać usługę apport.
Następnie uruchom ponownie aplikację, otrzymasz plik zrzutu w bieżącym katalogu.
źródło
Jestem na Linux Mint 19 (oparty na Ubuntu 18). Chciałem mieć
coredump
pliki w bieżącym folderze. Musiałem zrobić dwie rzeczy:/proc/sys/kernel/core_pattern
(przez# echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_pattern
lub przez# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
$ 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).
źródło
ulimit -c unlimited
sprawiło, że plik rdzenia poprawnie pojawił się w bieżącym katalogu po „zrzutu pamięci”.źródło