В подходе к обнаружению повреждения кучи я пытаюсь реализовать хеш-таблицу, чтобы хранить некоторую информацию о поврежденной памяти. Это делается внутри самой glibc. Когда мы malloc (), мы помещаем такую информацию, как адрес и размер, в хеш-таблицу, а когда мы free (), мы освобождаем соответствующую запись в хеш-таблице, опять же в самой glibc's free ().
Чтобы выделить память для хэш-таблицы, я использовал mmap'd некоторую память (воздержался от использования для этого malloc, поскольку вероятность повреждения кучи, вызванного процессом, также может повредить мою хеш-таблицу). Проблема в том, что нет ограничений на количество mallocs, которые может запросить процесс, это требует, чтобы моя хеш-таблица была расширяемой. Поскольку моя хеш-таблица работает с индексами массива, память, используемая для хеш-таблицы, должна быть непрерывной, чтобы с помощью индекса мы могли легко добраться до корзины или записи. Теперь, когда хеш-таблица использует всю память, мне нужно снова выполнить «mmap» таким образом, чтобы эта память начиналась там, где закончилась предыдущая. На странице руководства mmap говорится, что мы можем предоставить адрес для mmap, который будет действовать как подсказка ядру для отображения виртуальной памяти по этому адресу. Для хеш-таблицы это будет выглядеть как непрерывный кусок памяти. Я хотел бы спросить вас, насколько надежен этот подход и каковы возможные подводные камни при его использовании.
