>> Вот такой код может уронить приложение, поскольку страница вернулась системе:
>> free(p);
>> if (*p);
> Не должен бы.

Если освобождаемый блок окажется последним занятым в странице памяти, менеджер кучи может решить вернуть страницу системе и выполнит munmap(). Таким образом адресуемая указателем память окажется недоступна. Самое весёлое, когда подобное совпадение происходит в 1 случае из 100000.

> Не знаю, но подозреваю, что кернельские треды уже имеют
> преаллоцированные стеки.

Писал о них в #74. Размер 8К.

> Стеки юзерских процессов судя по наличию функции expand_stack()
> и отсутствию обратной ( https://github.com/torvalds/linux/blob/master/include/linux/...
> ) - только растут. Ну и по смыслу на каждое подергивание
> стека ходить в ядро и освобождать страницы - это очень дорогая
> операция.

Так free() это не стек. В куче предполагается хранить большие объёмы, а в стеке малые - потому в куче разумно предусмотреть возврат страниц системе, а в стеке они лишний.

> Кроме того, даже если ваша программа обратится в произвольную часть
> стека в пределах лимита на размер стека и там не окажется
> страницы то никто никуда не упадёт: возникнет исключение в котором ядро
> скорее всего тупо подложит страницу под ту область куда произошло обращение.
>> Тему сменили на обсуждение использования после освобождения, и я отвечал на вполне
>> конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не
>> оговаривается, потому я его вывел из условия "освобождённый" - то есть
>> не пересекает вершину.
> Ну я просто например не понял, почему там народ решил, что освобождение
> памяти в куче чем-то опаснее чем стек, потому и спрашивал.

Наверное, потому что аллоцировать на куче и сохранять указатель - обычная операция (другое дело, что потом с ним работа некорректна). А сохранять указатель на стековые данные - необычная. То есть стек используется как кратковременное хранилище, в таком сценарии перезапись свободной его части безопасна.

P.S. капча 66666 >*-)