Вопрос про malloc, когда оперативы доступной нет, и нет swap

Эксперимент был?

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

Так а что за прикол то будет?

segfault

да, виснет все( причем, маллок то нормально возвращает, а при обращении к якобы выделенной памяти все виснет. Кто то может это объяснить?

Что говорит cat /proc/sys/vm/overcommit_memory?

ref: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

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

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

Типа возвращает не NULL? Тут то как раз подляна, при нехватке памяти там не NULL, тебе кажется что нормально выделилось. Если я правильно слухи воспринял ;)

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

да, именно не NULL, потому что если бы NULL, приложение exit() сделало бы.

Ну, что поделать? reboot'ь, коннектся и смотри. То ли это — не скажу, но как минимум догадка. И да, настрой swap.

А ты посмотри чо там, запомни это значение как ошибочное...

embedded, свапа нет, на нанде свап делать не вариант. После ребута уже ничего не увидишь...

IIRC всё так. Возвращает не-NULL, а как по-делу — SegFault.

ТС, настрой ещё ulimits.

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

Что за железяка-то?

malloc никогда не вернет NULL. Хоть в чем-то царь правду говорил.

арм926

В нормальных OS вернёт ENOMEM. ;)

С вашими же Linux'ами грешу всёж на overcommit. (Но не проверял, т.ч. на правах догадки.)

а почему? есть какое то объяснение?

640k хватит всем. На том, по ходу, и порешили. ;)

В нормальных OS вернёт ENOMEM

Я в BSD не работал, увы. А в линуксе — да, пока не настроишь оверкоммит, будешь офигевать, не понимая причину сегфолта.

В линуксе ведро дырявое. Много косяков. Можно физически ограничить оверкоммитом, но тогда могут быть проблемы с говном от быдлокодеров (тормозиллой, хромоногим, либреохфисом и прочими быдлоподелками).

Тред об эмбедщиках, не знающих, что такое overcommit. Итерация 100500.

Эдик, у меня оффтоп, но важный.

У меня с твоей авы все глаза повытекли: http://s23.postimg.org/5p5gqzkw7/shvim.png

Замени её на пофикшеную: http://s23.postimg.org/n117yoozr/eddy_em.png

А при не настроенных ulimit, вполне и у ядра память отесть IMHO может.

Нет, любители овотарок должны страдать!

А ведь был способ чтобы был NULL в таких случаях...

Не перегибай. Я сделал тебе нормальную аву которая смотрится на любом цвете фона. Так ты хотябы мысль свою донесешь — прочесть смогут.

Ни разу не сталкивался. А вот с сегфолтами — да. Правда, чаще oom-killer убивает еще до сегфолта.

Покуда есть на ЛОРе авы, я буду всем нести ШГ! И нету на меня управы. Ну, разве только что JB...

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

не делай так :-)

выхода (чтоб получать заветный NULL и ENOMEM при malloc) вижу два с половиной: играть с опциями mallopt, брать/делать другой аллокатор, патчить libc`шный malloc на тему флагов mmap.

А что такого? Я как-то работал с пробитыми эмбеддщиками, под 10 лет опыта, но про оверкоммит они не знали, т.к. до этого работали исключительно с любимыми РТОС, и весь прогресс прошел мимо них.

Выключить оверкоммит вообще не вариант?

А что такого?

В безграмотности? Да ничего, это ж обычное дело.

Выключить оверкоммит вообще не вариант?

нехороший вариант - он меняет политику для всей системы. В упомянутой эмбедщине придётся впаивать в два раза больше памяти :-)

нехороший вариант - он меняет политику для всей системы. В упомянутой эмбедщине придётся впаивать в два раза больше памяти :-)

Это почему? O_O

Дык, одно дело — мелкоконтроллеры, и совсем другое дело — полноценная ОСь.

Да пошутил он. Не в 2, а в бесконечное число раз больше.

Да они и работали до этого с полноценной ртосью, POSIX-совместимой. Просто с линуксом не работали.

Это не безграмотность, просто люди до этого не работали с Linux.

Это почему?

образно: malloc(smallpie) может повлечь за собой mmap(largeblock) и так для всех запущенных процессов. Чтобы ничего не ломалось придётся гарантировать что памяти хватит на все largeblock, а в эмбеддед это только паяльником

Ладно, сольюсь. Я ни разу в жизни ртось не использовал.

парни, что можно сделать в моем случае? посоветуйте план действий пожалуйста

сказали же, вроде... «echo 2 | sudo tee /proc/sys/vm/overcommit_memory»

Запиши в /etc/sysctl.conf, скажем, так:

vm.overcommit_memory = 2
vm.overcommit_ratio = 100

я буду всем нести ШГ

Не слушай никого, оставь как есть. Буду всем показывать как эталон.

malloc
маленькими кусками в цикле
в цикле
malloc
malloc в цикле

Мне ли одному кажется что это какой то анти-паттерн? Во всяком случае в прикладном программировании.

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

malloc - это библиотечная функция. Она выделяет память только из области уже выделенной твоему приложению операционной системой. При нехватке памяти malloc может:
1) вернуть ошибку выделения - думай сам что делать
2) завершить твою программу аварийно
3) запросить память у ОС расширение сегмента данных вызовом brk
4) запросить память у ОС анонимное отображение в память вызовом mmap

В случае 3 brk при нехватке памяти вернет ошибку ENOMEM и далее malloc поступит по принципу 1 или 2

В случае mmap может быть упомянутое веселье - виртуальная память будет выделена но реальные страницы в нее не распределены. При попытке чтения или записи сработает прерывание по отсутствию страницы и ОС выполнит запрос на swap, если его нет то будет прибито самое зажравшееся памятью приложение. Возможно ваше, возможно другое. Если повезет и прибьют не вас то вам предоставят освободившуюся память.