Значение вывода pmap

В первую очередь, Ваше сообщение уже содержит название программы:

kernel: [11.895392] init: failsafe main process (631) killed by TERM signal

Это означает что программа failsafe с pid 631 полученный a TERM сигнал.

Для ответа на исходный вопрос никакое большинство дистрибутивов Linux не регистрирует pids созданных процессов на значение по умолчанию, но можно использовать контрольную платформу и создать необходимые правила зарегистрировать все созданные процессы. https://www.wzdftpd.net/docs/selinux/audit.html обеспечивает введение в эти правила и должен помочь Вам начать.

12
15.06.2014, 01:36
1 ответ

Сегмент текста является отображением в 0x400000 - это отмечено 'r-x' для читаемого и исполняемого. Отображение в 0x600000 только для чтения, таким образом, это - почти наверняка ".rodata" раздел исполняемого файла. GCC помещает литералы струны до в раздел только для чтения. Отображение в 0x601000 является 'rw-', таким образом, это - вероятно, знаменитая "куча". У Вас мог быть свой исполняемый файл malloc() 1 024 байта и распечатывают адрес для наблюдения наверняка.

Вы могли бы получить немного больше информации путем нахождения PID процесса и выполнения: cat /proc/$PID/maps - на моем ноутбуке Arch, который дает некоторую дополнительную информацию. Это выполняет 3,12 ядра, таким образом, это также имеет /proc/$PID/numa_maps, и catting, который мог бы дать маленькое понимание, также.

Другие вещи работать на исполняемом файле: nm и objdump -x. Первый может дать Вам общее представление о том, где различные вещи лежат в карте распределения памяти, таким образом, Вы видите то, что находится в разделе 0x4000000 по сравнению с другими разделами. objdump -x шоу Вы заголовки файлов ELF среди большого количества других вещей, таким образом, Вы видите все разделы, вместе с именами раздела и отображаются ли они во время выполнения или нет.

До нахождения записанного объяснения, "что то, где", необходимо будет сделать вещи как Google для "расположения памяти ФАЙЛА ELF". Знайте, что формат файла ELF может поддерживать более экзотические разметки памяти, чем, обычно привыкают. GCC и Гну ld и glibc, все делают упрощение предположений о том, как исполняемый файл занимается сексом и затем отображенный в память во время выполнения. Много веб-страниц существует, которые подразумевают документировать это, но только относиться к более старым версиям Linux, более старым версиям GCC или glibc, или только относиться к исполняемым файлам для процессоров типа х86. Если Вы не имеете его, добираетесь readelf команда. Если можно записать программы C, создайте собственную версию objdump -x или readelf познакомиться с тем, как работают исполняемые файлы, и что находится в них.

14
27.01.2020, 19:55
  • 1
    Большой ответ. Теперь, где "куча" программы? И что это [скоро] означает? Что я должен погуглить для обнаружения этого? –  Thorsten Staerk 17.12.2013, 23:08
  • 2
    Вы знаете что? Я был неправ относительно 0x601000 отображения адресов - это - "куча", вероятно. Необходимо будет использовать readelf или objdump для понимания этого, и безотносительно исполняемого файла, Вы сделали. Мое поле Linux Дуги использует/usr/lib/libc-2.18.so, таким образом, это очень отличается, чем Ваше поле. –  Bruce Ediger 18.12.2013, 05:22
  • 3
    0x601000 сегмент данных. Это содержит .data, .bss и может быть расширен через brk(). [anon] указывает, что нефайл поддержал память (так поддержанный подкачкой), полученный через mmap(). использование dlmalloc brk() для выделений, меньших, чем ~64Kb IIRC, и mmap() для больших выделений. "Куча" является всем выделенным malloc, и расширенная часть сегмента данных, и mmap()- основанные выделения. –  ninjalj 18.12.2013, 12:22

Теги

Похожие вопросы