Переполнение кучи в glibc и другое

Давай почитаем википедию?

Статья несколько запутанная, и говорят про разные уровни абстракции. Во-первых, самое главное ты процитировал.

memory appears to the program as a single contiguous address space

Вот это самая суть - программа видит память как одну непрерывную последовательность адресов.

То, что ты выделил жирным (пришлось исходник страницы смотреть т.к. у меня все посты и так жирным шрифтом через css)

The CPU can directly (and linearly) address all of the available memory locations without having to resort to any sort of bank switching, memory segmentation or paging schemes.

Это - уточнение к предыдущей фразе. В нём есть одна не очень хорошая формулировка («CPU can»), её следовало заменить на «процессор предоставляет программе такое abi» (как по англ не знаю сходу).

bank switching

Это технология из 1980-х и начала 1990-х, когда на одни и те же адреса физической памяти отображались разные её куски по запросу от проги. Называлась EMS. Нужна была вот зачем: проц адресовал только 1М (в реальном режиме), а памяти хотелось больше. Возможно, применяется где-то в ембеддеде сейчас.

memory segmentation

ну тут наверно всё понятно.

paging schemes

Тут да, речь как раз про страничную трансляцию, но стоит сделать уточнение.

В статье, судя по всему, речь идёт (в основном) про модель физической памяти. Если говорить именно про неё, то да, процессу она в качестве плоского пространства не видна. Но зачем так делать, я не знаю. Возможно, статья составлена с точки зрения ядра ОС, для которого память отдельных процессов конечно не плоская. Но когда говорят про память процесса, обычно говорят про другой уровень абстракции - логическую память, как раз то, что получается после трансляции. И это как раз то, что видно процессу в плоском виде.

Имеет. Линейная адресация означает, что все адреса представлены в памяти в виде одномерного массива.

Всё доступное процессу адресное пространство представлено в виде одномерного массива. «Все адреса» вообще - не должны.

Страничная не адресация а трансляция.

/me рыдает в истерике

Адресация остаётся линейной.

Пятиуровневая page table, адресующая через mmu DRAM – линейная адресация? Вот тебе адрес mapping’а в memory bank’е: 16R-2B-1BG-7C-1BG-3C.

Линейно, правда?

Зависит от обстоятельств. В большинстве случаев сегфолт, но вообще на эту ячейку можно выделить память.

Ну то есть тебе не доступна все память. Как же так, ведь у тебя линейная адресация :D

Язык тут ни при чём, это особенности платформы.

Адресация-то линейная. На уровне процессора. Откуда сегфолт? :D

Речь про то, что видно процессу.

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

Всё доступное процессу адресное пространство представлено в виде одномерного массива

Убейся об стену. Тебе три человека объясняют, что «линейная память» – всего лишь абстракция. Ни операционная система, ни процессор не работают с линейной памятью. Они работают с многоуровневой страничной адресацией.

И это, кстати, не делает адресацию линейной :D

Конечно не делает. Такой инкремент можно и в сегментной сделать. Только там он почти потеряет осмысленность, если ptr указывало на последний байт сегмента (результат может оказаться как в некорректном адресе, так и в начале этого сегмента, так и в начале какого-то другого). А тут - только если на последний байт памяти (0xFFFFFFFF для 32-битной).

Лулз в том, что это все ещё арифметика указателей, и ptr может быть хоть структурой с сотней полей

Не очень убедительная придирка, но ладно, можно тогда так, что б уж наверняка: next = (void*)(((intptr)ptr)+1);. Но вообще, ptr+i это синоним к (something*)(((intptr)ptr)+sizeof(*ptr)*i) за может быть мелкими исключениями. Но вот такое уже точно нежелательно к сегментной модели применять.

В статье, судя по всему, речь идёт (в основном) про модель физической памяти. Если говорить именно про неё, то да, процессу она в качестве плоского пространства не видна.

Ееее, у нас прогресс.

Но когда говорят про память процесса, обычно говорят про другой уровень абстракции - логическую память, как раз то, что получается после трансляции. И это как раз то, что видно процессу в плоском виде.

Только вот там нет плоского вида, лол:

$ cat /proc/$PID/maps
[...]
7f168b601000-7f168be01000 rw-p 00000000 00:00 0 
7f168c000000-7f168c0ba000 rw-p 00000000 00:00 0 
[...]

Мапинги рваные по самые не могу, и доступа к маппингам ты не имеешь. Все что у тебя есть – это указатели. Которые, внимание, НЕ РЕАЛИЗУЮТ ЛИНЕЙНУЮ МОДЕЛЬ. Они реализуют арифметику указателей, которая может хоть каждый раз ходить в таблицу трансляции и выдавать тебе на ptr+1 меньший логический адрес. Просто потому что это абстракция.

Не совсем внутри, но да, она спрятана от приложения и ему незачем об этом думать.

Не очень убедительная придирка, но ладно, можно тогда так, что б уж наверняка: next = (void*)(((intptr)ptr)+1);. Но вообще, ptr+i это синоним к (something*)(((intptr)ptr)+sizeof(*ptr)*i) за может быть мелкими исключениями. Но вот такое уже точно нежелательно к сегментной модели применять.

А тут ты можешь просто получить сегфолт на ровном месте, потому что испольуешь платформоспецифичное поведение :D

Не совсем внутри, но да, она спрятана от приложения и ему незачем об этом думать.

Ну и где эта «линейная модель» тогда? Ядро не использует, язык пользуется абстракциями указателей и арифметикой указателей.

Я просто поражаюсь такому фантастическому упрямству. Такое ощущение, что он свято верит, что современные компьютеры являются абсолютно точными реализациями модели фон Неймана. А защитные механизмы психики не дают ему осознать, что это представление не соответствует действительности последние 50 лет

Потому что он сишник.

На самом деле, он не виноват (ну, почти). Современные процессоры прямо заточены под исполнение кода на C и подобных языках. Отсюда вот вся эта срань с предсказателем ветвлений, скрытыми побочными эффектами, Meltdown, Spectre и тому подобной хтонью. Всё от того, что процессор должен быстро исполнять код на C.

Опять же, моя любимая статья: https://queue.acm.org/detail.cfm?id=3212479

На самом деле, он не виноват (ну, почти). Современные процессоры прямо заточены под исполнение кода на C и подобных языках. Отсюда вот вся эта срань с предсказателем ветвлений, скрытыми побочными эффектами, Meltdown, Spectre и тому подобной хтонью. Всё от того, что процессор должен быстро исполнять код на C

Ну, мне кажется, что OoOE и branch prediction – это в первую очередь следствие особенности современной памяти. У нас нет большего количества быстрой памяти с предсказуемой задержкой.

Не знал. Прям замапить? Интересная штука. А то и раньше было читерство - спровоцировать проц закешировать нужные адреса, а затем запретить ему кешировать новые, и те зависали в кеше навсегда.

про кэши всё равно надо помнить, если ты хочешь скорости от своего кода

Конечно надо.

Так что твоя модель памяти только прикидывается плоской и делает это из рук вон плохо.

Обычно вместо «прикидывается» это называют абстракцией. У жёстких дисков вот вообще на физическом уровне не может быть линейности в принципе, но по SATA интерфейсу они показывают одномерное LBA и никто не возражает что оно так называется. И SSD у которых внутри примерно та же страничная трансляция - она внутри, а снаружи то, что удобно (но для эффективного использования эти внутренности надо учитывать тоже).

Насчёт «делает плохо» - зависит от задач. Можно сказать что абстракция местами протекает, но не всегда это важно.

Но моё любимое – это всё равно NUMA.

А подробнее? Там изменения, сделанные одним процом, не сразу видны второму, или что?

Обычно вместо «прикидывается» это называют абстракцией. У жёстких дисков вот вообще на физическом уровне не может быть линейности в принципе, но по SATA интерфейсу они показывают одномерное LBA и никто не возражает что оно так называется. И SSD у которых внутри примерно та же страничная трансляция - она внутри, а снаружи то, что удобно (но для эффективного использования эти внутренности надо учитывать тоже).

Все так, у SSD плоская блочная адресация в виде массива. Чтение из любого блока вернет данные. Данные, а не сегфолт :D

Пятиуровневая page table, адресующая через mmu DRAM – линейная адресация? Вот тебе адрес mapping’а в memory bank’е: 16R-2B-1BG-7C-1BG-3C. Линейно, правда?

Нет. Но программа этого всего не видит. Она видит плоский адрес 0x12345678, всё остальное не важно и находится в зоне ответственности ядра ОС, проца и прочего железа. Ты не знаешь что такое уровни абстракции?

Это технология из 1980-х и начала 1990-х

Это гнилые досовские костыли. Дос, по сути, всегда был заточен исключительно на реальный режим и не умел использовать новые режимы адресации. Уже в 1985 году появился 80386б, реализующий страничную память и способный адресовать до 4 гигабайт памяти. С его появлениям начали развиваться вначале OS/2, а потом и Windows NT, которые работали в защищенном режиме

Тебе три человека объясняют, что «линейная память» – всего лишь абстракция.

Спасибо за информацию. 🤡 🪗 🪗 🪗 А я то, нуб такой, не знал. Теперь буду знать.

На самом деле, он не виноват (ну, почти). Современные процессоры прямо заточены под исполнение кода на C и подобных языках. Отсюда вот вся эта срань с предсказателем ветвлений, скрытыми побочными эффектами, Meltdown, Spectre и тому подобной хтонью. Всё от того, что процессор должен быстро исполнять код на C

Ну, мне кажется, что OoOE и branch prediction – это в первую очередь следствие особенности современной памяти. У нас нет большего количества быстрой памяти с предсказуемой задержкой.

Не совсем. Представь себе, например, проц с сотнями мелких ядер, у каждого из которых своя адресуемая память + доступ к общему банку. Программировать на C такое – ад и холокост, а вот на какой-нибудь Erlang – раз плюнуть. Задержки (локальной) памяти в таком сценарии тоже становятся куда более предсказуемыми, потому что нет многопоточности в пределах ядра и шина памяти целиком предоставлена твоему процессу/треду в любой отведённый ему квант времени. Т.к. многие треды довольно короткоживущие и работают в основном с небольшим куском памяти, то это резко снизит затраты на доступ в общий банк памяти в принципе.

Нет. Но программа этого всего не видит. Она видит плоский адрес 0x12345678

Нет, она не видит адрес 0x12345678. Она видит указатель. Это все что абстрактная сишная машина знает.

всё остальное не важно и находится в зоне ответственности ядра ОС, проца и прочего железа

И что в этой модели линейного-то? Я могу прочитать из ячейки 1? Нет? А из 2? Тоже нет? Ну и где линейность?

Она видит плоский адрес 0x12345678

Она видит указатель. Что находится внутри указателя – она не знает.

а вот на какой-нибудь Erlang – раз плюнуть

Эрланг позволяет прямо указать «локальность» выделенной памяти по отношению к тому или иному процессу, привязанному к конкретному вычислительному ядру?

Ты попросил популярные проекты, использующие раст.

Не надо врать. Я просил популярные написанные на расте. Таких не существует.

Форком какого проекта является fish?

Опять враньё. Я ничего про форки не говорил вообще.

Почему ты требуешь какой-то особой оригинальности от проектов на расте?

Написание 100500-го медиапроигрывателя или шелла означает всего лишь что на каком-то языке тоже можно написать медиапроигрыватель или шелл. Ничего более. И уж точно это не означает, что все должны всё бросить, и начать пользоваться этим языком.

По-твоему, на Си пишут много совершенно уникального кода?

Как бы практически весь нынешний стандартный набор софта изначально именно на Си и был написан. Разве что кроме emacs и других редких исключчений.

А то, что люборасты в принципе неспособны ничего своего придумать - это только слепому и глухому может быть неочевидно. Люборасты не творцы, они скорее паразиты.

cat /proc/$PID/maps

Ну да, не каждая страница адресного пространства процесса замаплена на физическую память. И не каждый адрес физической памяти замаплен на чип ОЗУ или на ещё какое-то устройство. Но адрес то всё равно есть.

Они реализуют арифметику указателей, которая может хоть каждый раз ходить в таблицу трансляции и выдавать тебе на ptr+1 меньший логический адрес.

Нет, указатели ни в какие таблицы трансляции не ходят. И вообще пока ты его не разыменуешь, он даже не попытается обращаться к соответствующей памяти. Меньший адрес может выдаваться если объект по указателю не влезает в память до её конца и там врап будет. Кстати подозреваю что по версии комитета такой указатель сам по себе UB.

А тут ты можешь просто получить сегфолт на ровном месте, потому что испольуешь платформоспецифичное поведение :D

Опять - когда попытаюсь разыменовать. Ну да, низкоуровневые операции с памятью зависят от платформы.

Не надо врать. Я просил популярные написанные на расте. Таких не существует.

А если ты закроешь глаза – мир вокруг исчезнет. Ага

Как бы практически весь нынешний стандартный набор софта изначально именно на Си и был написан

Если сто раз сказать «халва» – во рту слаще не станет. Тебе неоднократно указали на то, что это не так.

А то, что люборасты в принципе неспособны ничего своего придумать

Ты почему так прицепился к расту? У тебя в голове дихотомия: либо раст, либо Си?

Ну да, не каждая страница адресного пространства процесса замаплена на физическую память. И не каждый адрес физической памяти замаплен на чип ОЗУ или на ещё какое-то устройство. Но адрес то всё равно есть.

В сишной абстрактной машине адреса нет. Есть указатель :))

Нет, указатели ни в какие таблицы трансляции не ходят.

Почему нет? Я могу сделать такой процессор, где это требуется. Хоть голубями летать. И это, внезапно, будет работать.

И вообще пока ты его не разыменуешь, он даже не попытается обращаться к соответствующей памяти. Меньший адрес может выдаваться если объект по указателю не влезает в память до её конца и там врап будет.

Я могу сделать такую ОС, где у тебя сверху вниз адреса будут. И, повторюсь, в сишной абстрактной машине это будет работать без проблем. Проблемы начинаются, когда сишники вместо нормальной арифметики указателей начинают int’ы в указатели кастовать.

Линейная модель это то на чём базируется арифметика указателей. Если, конечно, платформа с линейной моделью а не дос например.

Неплохо бы ещё к каждому упомянутому пункту написать что это вообще и чем оно лучше аналога. А то какой-то набор неизвестных буквосочетаний абсолютно ничего не говорящий тому кто не состоит в вашей секте.

Опять - когда попытаюсь разыменовать. Ну да, низкоуровневые операции с памятью зависят от платформы.

На самом деле нет. Потому что если пользоваться арифметикой указателей, то компилятор обо всем позаботится. Проблемы начинаются, когда сишники начинают int’ы в указатели кастовать на ровном месте.

Линейная модель это то на чём базируется арифметика указателей. Если, конечно, платформа с линейной моделью а не дос например.

Это тебе кто сказал?

Ну да, не каждая страница адресного пространства процесса замаплена на физическую память

Не каждая. А еще страницы выделяются не поштучно, а блоками. А еще процесс знать не знает ни про какие страницы. У процесса есть указатели. Которые – сюрприз! – реализуют многоуровневую страничную адресацию. Когда до тебя это дойдет?

Линейная модель это то на чём базируется арифметика указателей

Нет. Она давно не базируется на линейной модели.

Чтение из любого блока вернет данные

Там вместо сегфолта заглушка на возврат либо «все нули» либо «все единицы». Размапить страницу на ssd очень просто, это делается fstrim/blkdiscard. При записи контроллер её мапит автоматически назад. Кстати интересно почему в ОС нигде такого нету.

Там вместо сегфолта заглушка на возврат либо «все нули» либо «все единицы». Размапить страницу на ssd очень просто, это делается fstrim/blkdiscard. При записи контроллер её мапит автоматически назад. Кстати интересно почему в ОС нигде такого нету.

Это не поменяет ситуацию. У тебя есть массив [0; N], на которым валидны операции чтения/записи. В C у тебя такого нет :)

Не знал. Прям замапить?

Cache as RAM в Linux

Смотри туда. Там ссылка на PDF есть.

Обычно вместо «прикидывается» это называют абстракцией.

Нет, это не абстракция. Это притворство.

У жёстких дисков вот вообще на физическом уровне не может быть линейности в принципе, но по SATA интерфейсу они показывают одномерное LBA и никто не возражает что оно так называется.

Её и у памяти нет лол! Там номера дорожек и ячеек, и их ещё и обновлять надо, шоб заряд не утёк. Только ты об этом не знаешь, зато знает твой процессор. И хотя бы поэтому твоё утверждение что «указатели в C такие же как в процессоре» как минимум является очень большой натяжкой совы на глобус, а скорее всего просто ложью.

С другой стороны, что мешает объединить номера дорожек и секторов у вертушек в одно число? Или даже приделать к этому страничную адресацию. А, погоди ж… это же указатели!

Насчёт «делает плохо» - зависит от задач. Можно сказать что абстракция местами протекает, но не всегда это важно.

«Не всем нужны нетекущие абстракции» (c) почти saahriktu

Но моё любимое – это всё равно NUMA.

А подробнее? Там изменения, сделанные одним процом, не сразу видны второму, или что?

Например, да. Чаще всего ты это замечаешь по внезапно возникшим дедлокам там, где их раньше не было, потому что два треда на разных процах решили одновременно что-то залочить.

В сишной абстрактной машине адреса нет. Есть указатель :))

Те, кто пишут исключительно на абстрактной машине (которую пиарят адепты комитета), адреса и не использую. Но Си более универсальный язык и позволяет адреса таки использовать, хотя бы через тайпкасты в uint. И все современные компиляторы при тайпкасте показывают именно настоящий адрес указателя, а не какие-то условные числа.

Те, кто пишут исключительно на абстрактной машине (которую пиарят адепты комитета), адреса и не использую.

Единственные, у кого есть оправдание использовать реальные адреса – ядро и прочий baremetal. Потому что там надо. Всем остальным не надо.

Но Си более универсальный язык и позволяет адреса таки использовать, хотя бы через тайпкасты в uint.

А потом огребают на портировании софта на другие архитектуры. Плавали, знаем. Есть буквально ноль (0) разумных причин этим заниматься. Что, конечно же, не останавливает быдлокодеров.

хотя бы через тайпкасты в uint

Блажен, кто верует

Неплохо бы ещё к каждому упомянутому пункту написать что это вообще и чем оно лучше аналога. А то какой-то набор неизвестных буквосочетаний абсолютно ничего не говорящий тому кто не состоит в вашей секте.

Ну то есть, ты на форуме посвященному Линукс с 2009-го года, читаешь и пишешь ежедневно, напостил на пять звезд, и ни разу не слышал про Alacritty. Не слышал про ripgrep. Серьезно? Не забывай принимать таблетки, мужик, тебе их не просто так прописали

Например, да. Чаще всего ты это замечаешь по внезапно возникшим дедлокам там, где их раньше не было, потому что два треда на разных процах решили одновременно что-то залочить.

То есть предоставляемые операционной системой механизмы синхронизации типа мютексов багаются от этого, при этом ОС разумеется знает что там NUMA, видит что вот треды одного процесса и всё равно раскидывает их так что они багаются, если только ей вручную не подсказать? Это только в линуксе так или везде?

а вот на какой-нибудь Erlang – раз плюнуть

Эрланг позволяет прямо указать «локальность» выделенной памяти по отношению к тому или иному процессу, привязанному к конкретному вычислительному ядру?

Erlang знать не знает ни про какую память, поэтому ты можешь сделать реализацию для такого вот проца и всё будет работать. Там нет указателей, они просто не нужны, на самом деле. Сишники за них уцепились, потому что больше ничего не могут осилить.

Другой вопрос, что в современных языках с GC давно замечено, что большая часть значений, которые используются кодом, живут недолго и часто занимают очень мало места. Поэтому в современных GC есть такая штука как «ясли» (nursery), где по дефолту создаются все объекты меньше какого-то определённого размера. Большинство из них не переживёт цикл сборки мусора, поэтому аллокация в «яслях» очень дешёвая и быстрая. Обычно эти «ясли» рантаймом делаются равными по размеру L2-кэшу проца. В результате, большая часть данных, с которыми работает твой код, в основную память просто не улетают.

Это происходит когда когерентность процессоров нарушается. Этим грешат паверы, например.

А я то, нуб такой, не знал

Если ты знал, почему ты форсишь свою чушь про линейную адресацию?

А потом огребают на портировании софта на другие архитектуры.

Если твой софт обслуживает железку, которая гвоздями прибита к конкретной архитектуре, то портировать его никуда не придётся.

Или если твой софт например патчит конкретные x86-инструкции в каком-то другом бинарнике, то очевидно что портировать его никуда не нужно. А если тот софт, который он патчит, окажется на другой архитектуре, то патчер придётся скорее всего не портировать а переписывать заново но другой ассемблер итд.

Ты ж уже сам признал, что такая абстракция имеет место, почему продолжаешь предъявлять то?

Например, да. Чаще всего ты это замечаешь по внезапно возникшим дедлокам там, где их раньше не было, потому что два треда на разных процах решили одновременно что-то залочить.

То есть предоставляемые операционной системой механизмы синхронизации типа мютексов багаются от этого

Не. Багаются сишные костыли, которые многие сишные быдлокодеры с собой таскают ради переносимости. Собственную реализацию мютексов, например, потому что херли бы и нет? Ведь в C нет примитивов для синхронизации, pthread() – лялексовая штука и на той же венде отсутствует. Так-то лялексовый futex не должен от этого страдать.

при этом ОС разумеется знает что там NUMA, видит что вот треды одного процесса и всё равно раскидывает их так что они багаются, если только ей вручную не подсказать? Это только в линуксе так или везде?

В венде и лялексе, как минимум. А почему бы не раскидывать разные треды на разные процы? В теории, всё же должно работать лол.

Кстати, всякие хачкели, сишарпы и прочие жабы нативно умеют NUMA и погроммисту даже думать об этом не надо. А вот сишники как всегда огребают из-за своего убогонького недоязычка.

Если твой софт обслуживает железку, которая гвоздями прибита к конкретной архитектуре, то портировать его никуда не придётся.

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

Или если твой софт например патчит конкретные x86-инструкции в каком-то другом бинарнике, то очевидно что портировать его никуда не нужно.

Ну мы не про такой софт, правда?

Эта абстракция не используется современными операционными системами и современными процессорами.

В венде и лялексе, как минимум

Не, если синхронизационные примитивы не багаются то всё норм.

Зачем свои делать, если пишешь для мейнстримных ОС, не знаю, они в винде хоть и отличаются но тоже есть - проще задействовать готовые по-любому.

Хотя про то что своя реализация может багнуться я не знал.

Ты почему так прицепился к расту?

Я прицепился вовсе не к расту. Против самого раста, как ещё одного языка программирования я ничего не имею. Я прицепился к секте люборастов и к тем, кто контролирует ресурсы с ним связанные и толкает в программирование подходы ни к расту ни к программированию никакого отношения не имеющие.

Я прицепился к секте люборастов и к тем, кто контролирует ресурсы с ним связанные и толкает в программирование подходы ни к расту ни к программированию никакого отношения не имеющие.

Ты уже нашел себе мужика?