C free() на виртуальной машине Ubuntu, вопрос относительно кучи памяти

Почему вы ожидаете чего-то особенного? Что происходит с освобожденной памятью, языком не определяется.

Функция free() не гарантирует, что что-либо изменится. Все, что делает free(), — это делает эту память доступной для последующих вызовов malloc, calloc и т. д. Это хорошо, что free() работает таким образом, ведь зачем C программисту тратить циклы на free() изменение ячеек памяти?

Почему вы этого ожидаете?

Если это просто любопытство, то скажите об этом в вопросе. В противном случае, если у вас есть реальная проблема, с которой вы пытаетесь получить помощь, спросите об этом напрямую.

@PaulMcKenzie Что удивительно, так это то, что это меняет память.

@Barmar - Может быть, запускаемая сборка неоптимизирована?

@PaulMcKenzie Зачем неоптимизированному free() изменять память? Это больше похоже на то, что они используют отладочный malloc, который использует это для обнаружения двойного освобождения.

Привет, Бармар, спасибо. Потому что в примечаниях glib malloc.c указано, что два указателя перезаписывают первую строку данных, а заголовок включает в себя предыдущий размер фрагмента и отбрасывает флаг P.

Поскольку это Ubuntu и, следовательно, предположительно glibc, нужно иметь в виду, что glibc использует кэширующий распределитель, т.е. не каждый malloc приводит к вызову ОС для получения дополнительной памяти, и не каждый свободный возвращает память обратно ОПЕРАЦИОННЫЕ СИСТЕМЫ. Вместо этого он поддерживает пул заранее выделенной памяти, из которого пытается удовлетворить требования программы, чтобы ускорить работу. Глядя на исходный код, становится ясно, что реализация тегов free() освободила память, указывая на то, что она теперь принадлежит glibc, а не приложению, и, следовательно, может повторно использовать ее для большего количества вызовов malloc(). Все во имя скорости.

Привет, Базза, спасибо за это, ты случайно не знаешь, какими могут быть данные во второй строке?

@bazza Именно так работает большинство реализаций malloc, в glibc нет ничего особенного.

откуда взялся адрес 0x555555559290?

Привет, Яно, это на 16 байт меньше, чем указатель b1, показывающий первый заголовок.

@barmar glibc даже не был первым, но этот метод далеко не вездесущ, поскольку некоторые платформы предпочитают надежность, получаемую при постоянном получении выделений из ОС. Подход glibc быстрый, но более склонен к тому, что ошибки памяти остаются незамеченными. Например, у меня есть блок-графы для GNU Radio (предопределенные блоки C++, связанные вместе с Python), которые прекрасно работают в Linux, но тот же самый код, созданный и запущенный во FreeBSD (которая использует другой распределитель), приводит к сбоям в сегментировании. Следовательно, в GNU Radio есть ошибки памяти, которые никто не находит, потому что большинство из них запускают его на Linux/glibc...

@ rdre8 см. ответ Марко Бонелли

@Barmar, меня несколько позабавил рост популярности кэширующих распределителей, потому что для кода, который меня волновал, я годами делал нечто подобное в исходном коде приложений. Мотивация заключалась в первую очередь в том, чтобы ограничить использование резервных буферов трансляции (на PowerPC). Выделив всю память моего приложения в одном malloc(), а затем разделив ее в исходном коде, можно было бы избежать забивания TLB в процессорах внутри циклов DSP, которые должны были быть быстрыми и в реальном времени. К счастью, в таком коде все выделение памяти выполняется до горячего цикла, поэтому сделать это было не очень сложно.

Примечательно, что gcc может и будет полностью оптимизировать некоторые из этих вызовов malloc, если у вас включена оптимизация.

@bazza AFAIK, это самый старый метод, поскольку изначально в Unix был только один способ получить память от ОС, и это был sbrk(). Это могло расширить/сжать сегмент данных только на одном конце, поэтому единственный раз free() мог вернуть память, это если вы освобождали выделение на этом конце. Альтернативы стали доступны только тогда, когда был добавлен mmap() (я думаю, в BSD), но немногие реализации malloc() воспользовались этим.

@Бармар, я этого не знал - большое спасибо!. Я давно начал использовать другие POSIX-подобные операционные системы (например, VxWorks), которые всегда имели только простые распределители, которые каждый раз работали непосредственно с ОС (в такой RTOS, как VxWorks, штрафов было меньше). Я не осознавал, что старые Unix не реализовали сегодняшнее понимание malloc() и free(). Это напоминает мне о том, как много операционных систем не реализовали select() или потоки вплоть до начала 90-х годов.

Это выдающийся ответ, Марко, спасибо, что уделили время этому вопросу. Я искал предлог, чтобы углубиться в надстройки gdb gef/peda/pwndbg, и теперь у меня есть идеальный повод.

Отлично, я не знал о настройке mxfast.