GNU C Library v2.30

Пора пересобирать WORLD.

От позорных сегфолтов вроде Баг в libc или я не умею читать стандарт??? GNU’шники вычистили наконец свою либу? Или забили хрен?

Урра. не прошло и полгода

Andreas Schwab Пофиксил баг в 2.30, после того как недавно ещё несколько подтверждений вылезло.

Баг в libc или я не умею читать стандарт??? (комментарий)

Ebuild-ы уже конечно же отсутствуют :)

Видел тред на одной странице.

Ebuild-ы уже конечно же отсутствуют :)

«Ждём-с»

такая же мысль сразу пришла в голову :)

ну что ж, иногда надо это делать. впрочем, у меня сборки с libc живут только для тестирования и я их редко использую.

А вот к примеру, во FreeBSD таких багов меньше?

Я тоже, кек.

Не знаю, не пользуюсь FreeBSD.

Видел тред на одной странице.

я тоже.

давно не слежу за мелочами, где то лет более 10, они от sbrk избавились? перешли на mmap? аллокатор (то что про всякие malloc family) того - поменяли? а то раньше кошмар был и ужас, и поэтому понаделали полурабочих libc. сейчас то памяти до хера за недорого, но просто зачем , да и интересно там как что.

removed in POSIX.1-2001.

да, хорошооо и наконец то, выпилен был позднее, но это уродие выпилено. отлично.

да, хорошооо и наконец то, выпилен был позднее, но это уродие выпилено. отлично.

Ну да, ну да. Вначале в угоду тупой архитектуры отказаться от защиты памяти от конца реальных и запрошенных данных до границы страницы, а потом, оппа, sbrk() вдруг стал уродливым... Прогрес, чо.

После 2.30 они зафиксили его и в более ранних 2.25, 2.26, 2.27, 2.28 2.29. Так что одними детскими граблями меньше.

Мне одному показалось, что Musl развивается семимильными шагами, по сравнению с сабжем? А LLVM сообщество хочет новую libc запилить, что, собственно, правильно. И даже хотели за основу взять musl, но автор заарканился.

Ну так musl догоняет просто, не?

По фичам и поддержке новых стандартов Си уже перегнала года 2 как, не?

Ну например? Я просто не знаю. Кроме нинужных тхриадов.

Ну да, ну да. Вначале в угоду тупой архитектуры отказаться от защиты памяти от конца реальных и запрошенных данных до границы страницы, а потом, оппа, sbrk() вдруг стал уродливым... Прогрес, чо.

вот это ты сейчас к чему а? sbrk() изначально уродливые архитектурно метод, понаоткусывают памяти и она все.

sbrk() изначально уродливые архитектурно метод, понаоткусывают памяти и она все.

А вы этот метод вообще знаете? Что там уродливого - увеличить/уменьшить границу .data? Уродливо как раз mmap(anon), где получение памяти произошло только из-за прикола: «а что бы такого это должно делать на /dev/zero? А, пусть будет получение памяти».

А вы этот метод вообще знаете? Что там уродливого - увеличить/уменьшить границу .data? Уродливо как раз mmap(anon), где получение памяти произошло только из-за прикола: «а что бы такого это должно делать на /dev/zero? А, пусть будет получение памяти».

да, и что в этом хорошего? такой метод позволил писать клевые аллокаторы, когда изза кусочка меньше страницы где то в конце или начале мы не можем отдать память системе. и это вместо того чтоб сделать набор пуллов памяти для аллокатора - тем самым эффективно расходовать ее, и да - если пул свободен - отдать обратно странички системе. и я про тот случай когда уже мы не бегаем в page fault, а когда уже всем виртуальным страничкам физические подставили. уродливый ваш sbrk

Я не о том, что надо выбросить mmap и снова юзать sbrk. Я о том, что во времена первых Unix-ов sbrk был весьма нормальным сисколом, в той же винде работа с памятью имеет чудовищный и противоречивый API. А mmap сам по себе правильный сискол, но для файлов. Для памяти он появился случайно, в явно убогом виде, так как оно было притянуто за уши и не до сих пор между прочим не совсем с едиными для всех OS параметрами.

А mmap сам по себе правильный сискол, но для файлов.

все это файл, и память тоже. так что все правильно там сделано.

Для памяти он появился случайно, в явно убогом виде, так как оно было притянуто за уши и не до сих пор между прочим не совсем с едиными для всех OS параметрами.

есть POSIX, есть OS специфичные флаги - не вижу никаких проблем.

в той же винде работа с памятью имеет чудовищный и противоречивый API.

то что сделано там - на то равняться вообще не стоит, даже лучше не смотреть, а если привиделось, то лучше поскорее развидеть.

все это файл, и память тоже. так что все правильно там сделано.

Пф, сдаётся, что пора прекращать, смысл спорить, если вам по вопросу сказать нечего? Файл - это когда есть дескриптор. Пока был дескриптор от /dev/zero, оно ещё было похоже, но тоже натянуто, так как /dev/zero тоже не настоящий файл, а блочное устройство с программной эмуляции некой несуществующей абстракции. Но потом пришла следующая гениальная идея, а зачем нам вообще там файл? Давайте просто заделаем новый флаг MAP_ANONYMOUS.

Оперирование словами вроде «уродливости» и апеллирование к истории не тянет на спор «по вопросу». Так, балабольство.

Так, балабольство.

Отож. По мне так было просто очередное можно-молодёжно, а всё остальное — уродство. Начинаешь выяснять, ну почему, если ну явно же ровно наоборот, и пошло поехало: почему-отчего не важно, главное как тут любит кто-то выражаться — «кукарекнуть».

Пф, сдаётся, что пора прекращать, смысл спорить, если вам по вопросу сказать нечего? Файл - это когда есть дескриптор. Пока был дескриптор от /dev/zero, оно ещё было похоже, но тоже натянуто, так как /dev/zero тоже не настоящий файл, а блочное устройство с программной эмуляции некой несуществующей абстракции. Но потом пришла следующая гениальная идея, а зачем нам вообще там файл? Давайте просто заделаем новый флаг MAP_ANONYMOUS.

я привел аргумент почти в самом начале, не надо ляля. вы тут за сисколл «нормальный», который порождал уродства, и в итоге более менее жирные софтины память не отдавали системе. mmap() с nofd и MAP_ANONYMOUS - вполне себе решение, и лучше чем sbrk(), куда гибче. Или надо создавать еще один сисколл типа void *virtmap(const void *start, uintptr_t size, int flags) ? а потом наплодить еще побольше, и, в итоге заиметь адилово аля win-way?

и не надо тут заливать про модно стильно молодежно, этот «новый» путь решил проблему - решил, стало гибче и лучше - стало, не навертели 33 слоя сверху и куча ненужного гавно - не навертели. electron или там любая хипстерская херь типа эмодзи - это гавно и не нужно, а mmap() для виртуальной памяти без мапинга на какое то устройство - вполне себе подход, хотя, возможно, не самый лучший.

Этот «новый путь» родился тогда, когда многие тут ещё не родились. Но в то же время родилось ещё огромная куча сисколов. В отличии от изначальной унификации стройной системы сисколов почему-то та эпоха отличалась натуральным уродством. Что select, что mmap — никакого чувства вкуса и стандартизации.

Последний китайкий раз: (s)brk — устаревший сискол, но по уродству mmap переплёвывает его на порядки.

Вначале в угоду тупой архитектуры отказаться от защиты памяти от конца реальных и запрошенных данных до границы страницы,

Ты лично готов всем заменить оборудование на «нетупое» бесплатно или что?

в той же винде работа с памятью имеет чудовищный и противоречивый API.

Норкоман? VirtualAlloc + VirtualFree полностью покрывает все «пользовательские» нужды. VirtualProtect «хакерам» для изменения доступа. VirtualLock - позволяет выйти на физику, ну и человеческий VirtualQuery позволяет разузнать о состоянии адресного пространства всё, что нужно.

Плюс нормальная поддержка 4+Gb памяти для 32-битных процессов.

Уж где-где, а в венде самый нормальный API для работы с адресным пространством.

Но потом пришла следующая гениальная идея, а зачем нам вообще там файл? Давайте просто заделаем новый флаг MAP_ANONYMOUS.

В каком смысле «потом»? Этот очевидный косяк в POSIX'овом API был исправлен практически везде. Только тормоза из стандарта тормозят.

В каком смысле «потом»?

В прямом.

Этот очевидный косяк в POSIX'овом API был исправлен практически везде.

И этот человек восхищается виндовом API управлением памяти. Вам бы c крестиком или с трусиками определиться надо, перед тем как зуд свой чесать в бла-бла ради поспорить.

Этот «новый путь» родился тогда, когда многие тут ещё не родились.

я не собирал статистику кто когда тут родился. но давно да, я с этим не спорю. это вы тут обозвали mmap с флагом MAP_ANONYMOUS хипстерством, хотя тогда хипстеров то и не было, и повального - «оно лучше только потому что новое».

но по уродству mmap переплёвывает его на порядки.

не согласен, но это уже в сторону фломастеров, я бы сделал отдельный сисколл для управления памятью, с флагами ... хотя ... ах да - похоже это на mmap(). а какие ваши варианты?

ах да - похоже это на mmap(). а какие ваши варианты?

Да нисколько не mmap. Для отображения файла еще куда не шло необходимость шести(!) параметров у сискола, а зачем это для получения памяти?

Да нисколько не mmap. Для отображения файла еще куда не шло необходимость шести(!) параметров у сискола, а зачем это для получения памяти?

ну можно подсчитать, адрес куда мапить надо(1), размер надо б таки указать(2), флаги нужны пожалуй(3), права на кусочек надо б установить(4). 4 аргумента. хм, то есть делать еще один сисколл ... ну такое себе оно. хотя, конечно, при том зоопарке сисколлов (привет монолитные ядра - они такие да), можно и добавить, +- 1 syscall красивее все это общесистмное спагетистое уродство не сделает, но и mmap() такой какой он есть тоже не делает погоды на всем том общем фоне и архитектуре.

ну можно подсчитать, адрес куда мапить надо

А потом на этом соорудить malloc, которому нафиг этот адрес куда не нужен, и потому он там NULL. Права тоже в общем-то надо только для загрузки библиотек, то есть не собственно памяти, а файла. Для шареной памяти сисколы уже были и есть отдельные. А что за флаги? Флаг то один MAP_ANONYMOUS, который в других системах обозвали как MAP_ANON.

А потом на этом соорудить malloc

OMG, malloc совсем для других вещей, он не для выделения вирт памяти, а чтобы выделить память аллокатором что сверху, и без выравнивания по размеру страницы, вы вообще в курсе как это происходит.

а стек для тредов как аллокейтить??? похоже вы в системной разработке плаваете.

Права тоже в общем-то надо только для загрузки библиотек, то есть не собственно памяти, а файла

дооо, как все запущено, а .rodata бинарника ? да и куча других кейсов.

А что за флаги? Флаг то один MAP_ANONYMOUS

флаг чтоб сразу подставились страницы физические на выделенные виратуальные например, не надо шланговать, либо запросить чтобы физические страницы шли подряд, а еще важно, например, отметить чтоб эти страницы не могли в своп поехать. brk/sbrk полное гавно, по сравнению с mmap. кроме того mmap есть не только на файлы, а еще на объекты IPC.

malloc совсем для других вещей, он не для выделения вирт памяти

Что за бред?

а стек для тредов как аллокейтить???

Как как. Это такая же обычная память:

map_addr = mmap(NULL, stacksize + guardsize,
                      PROT_READ | PROT_WRITE | PROT_EXEC,
                      MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

похоже вы в системной разработке плаваете.

Вот кто бы говорил.

дооо, как все запущено, а .rodata бинарника ? да и куча других кейсов.

Вот именно. Как всё запущено. .rodata для бинарника аллокируется или excec-ом при старте процесса, либо загрузкой so-шек, то есть именно файлов. Кейс, когда надо получить память, но невозможно туда ничего поместить, имеет место быть, но судя по всему вы его не знаете, так как написали набор чуши, а не об этом.

флаг ...

Не надо это бла-бла. Перечислите флаги, которые юзаются для получения памяти, кроме MAP_ANON.

а еще на объекты IPC

shmem отдельный набор сисколов.

Что за бред?

это не бред. malloc это управление выделенной памятью, mmap/sbrk и co управление выделением памяти. или если вам надо 512 байт вы их sbrk/mmap выделяете? а на оставшийся кусок страницы забиваете?

Как как. Это такая же обычная память:

нафейхуа везде EXEC? это обычная память никто не спорит, как ее выделить в отдельном виртуальном куске с sbrk? это раз - и не надо тут шланговать - вы сказали что sbrk лучше и все покрывает.

.rodata для бинарника аллокируется или excec-ом при старте процесса, либо загрузкой so-шек, то есть именно файлов.

а exec волшебным образом работает, и ld.so инопланетяне с помощью sbrk пишут.

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

чушь тут пишете только вы, в реальности нужно мапить n страниц на RO в которое кто то другой пишет, а процесс (какая либо ф-ция libc) атомарно вычитывает, но вы продолжайте нести ахинею.

Не надо это бла-бла. Перечислите флаги, которые юзаются для получения памяти, кроме MAP_ANON.

Вам реальные примеры из жизни привели, но да ладно - MAP_FIXED, из не POSIX куча, для того же стека (которая обычная память спору нет, только растет в другую сторону) - MAP_GROWSDOWN, MAP_POPULATE - в уже приведенном мною кейсе, ну и в целом я привел кейсы до этого - а вы шлангуете либо, как я уже заметил, плаваете в вопросе.

так что прекращайте нести ахинею и разводить бла бла бла. sbrk гавно by design, mmap куда гибче и удобнее. ну а то что сисколлы не стандартиризировали - так это уже другой разговор, монолитные ядра они такие себе.

shmem отдельный набор сисколов.

ага POSIX realtime extensions, и тоже уродливо. shmat() аллоцирует, shmget создает - забыл уже там точно как. но суть такая же.

если вам надо 512 байт вы их sbrk

Представьте себе, когда-то так и было. Если, конечно, не было подходящего куска после free().

нафейхуа везде EXEC?

А по умолчанию. И вообще, код взят из pthread_allocate_stack

и не надо тут шланговать - вы сказали что sbrk лучше и все покрывает.

Брешешь. Я говорил только одно — mmap для памяти можно было сделать отдельным неуродливым сисколом. А sbrk после того, как памяти стало не 64k на процесс у первых юнисков, — устарел.

а exec волшебным образом работает,

И этот поц что-то там кукарекает о системном программировании. Да, волшебным, это сискол, он ничего в пользовательском окружении не аллокирует.

в реальности нужно мапить n страниц

Кому нужно? Межпроцесорному взаимодействию? Так это опять отдельная история, у которой уже было решение до изобретения mmap для памяти, ибо в общем случае передать адрес другому процессу невозможно, память она таки виртуальная. Для одного процесса это тоже можно применить, но вы опять не смогли продемонстрировать понимание этого кейса.

Вам реальные примеры из жизни привели,

Вот только вы в них путаетесь. То у вас моды доступа не флаги, то у вас POPULATE, хотя это вообще для мапинга файлов. Что будет с FIXED без MAP_ANON?

так что прекращайте нести ахинею и разводить

Вот и прекращайте. Чего позориться то?

Представьте себе, когда-то так и было. Если, конечно, не было подходящего куска после free().

опять шлангуешь. это было настолько давно ... даже не знаю.

А по умолчанию. И вообще, код взят из pthread_allocate_stack

бла бла бла бла бла

Брешешь. Я говорил только одно — mmap для памяти можно было сделать отдельным неуродливым сисколом. А sbrk после того, как памяти стало не 64k на процесс у первых юнисков, — устарел.

не надо уже отмазываться таки. вы написали там, мол sbrk лучше mmap и mmap не нужен и тд. я вам ответил, что sbrk недостаточно и не гибко.

И этот поц что-то там кукарекает о системном программировании. Да, волшебным, это сискол, он ничего в пользовательском окружении не аллокирует.

ваши кукареки смешны. а теперь жду реализации ld.so с sbrk()

Кому нужно? Межпроцесорному взаимодействию? Так это опять отдельная история, у которой уже было решение до изобретения mmap для памяти, ибо в общем случае передать адрес другому процессу невозможно, память она таки виртуальная. Для одного процесса это тоже можно применить, но вы опять не смогли продемонстрировать понимание этого кейса.

да это вы позориться перестаньте. причем тут межпроцессорное взаимодействие?

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

а передать идентификатор, замапить на RO в специально подготовленный вирт адрес, и вернутся из сисколла без копирований в kernel space туда обратно, а тупо замапив память - это конечно вам не приходит в голову, тк вы плаваете опять.

Вот только вы в них путаетесь.

нет, это вы путаетесь, вам флаги не нужны - вы опять шлангуете.

то у вас POPULATE, хотя это вообще для мапинга файлов

ну прекращайте уже позориться, POPULATE не только для файлов, оно нужно для того чтоб вы не бегали в ядро изза page fault при обращении к памяти, тогда, когда это критично, чтобы у вас уже подмаплены были страницы.

хотя это вообще для мапинга файлов. Что будет с FIXED без MAP_ANON?

сначала ld.so на sbrk и остальные кейсы на нем. либо альтернативы - без флагов и прочего, с минимумом аргументов.

Вот и прекращайте. Чего позориться то?

тут только вы позоритесь. я рекомендую вам уже остановиться.

опять шлангуешь. это было настолько давно ... даже не знаю.

Ну так просвещайтесь. Мне не трудно. В моём старческом сленге «шлангуешь» — увиливать от работы, как правило без отрицательной коннотации у отчитываемого. То есть, клоунский бред несёте.

не надо уже отмазываться таки

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

Ну так просвещайтесь. Мне не трудно. В моём старческом сленге «шлангуешь» — увиливать от работы, как правило без отрицательной коннотации у отчитываемого. То есть, клоунский бред несёте.

я к тому что это было настолько давно, что рассматривать не имеет смысла. клоунский бред несете тут вы, вам аргументы, а вы кроме кукареку ничего по делу не ответили. вы увиливаете от ответов - поэтому термин «шланговать» очень тут кстати.

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

Переход на личности, как ожидаемо от человека, который плавает в теме и ничего не может по теме ответить.

Можно не отвечать, в игноре видно не будет.

«оно обиделось» (c) не помню чей. как тут раньше говорили - «слив засчитан»