Как вы освобождаете после realloc-fail?

Но если рассматривать только линукс и только сейчас

Сударь, если вы склонны именно так рассматривать, то вы - говно. Это если тезисно и без лишних букв.

Что значит "?"? Т.е. хапнули 2 Гб, хапнули еще 4кб, 4кб зафейлилось, кто 2 Гб освобождать будет? Пушкин?

Так после смерти процесса вся используемая им память освобождается же.

Стандартный виндовый пример - «файл не может быть открыт так как файл занят другим процессом». Часто не разлочивался после внезапного убийства процесса.

И что вы делали в таком случае? Комп что-ли перезагружали? P.S. В Linux'e ничего подобного не видел. Все открытые дескрипторы при смерти закрываются.

На кой хрен вызывать free перед выходом из программы?

А я и не знал, что вы из этих...

Такое бывает? O_o...

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

Конечно. И обрабатываю все ошибки и тестирую, так делает любой программист в отличие от быдлокодеров типа цАРЯ.

C нимбом все ок? ;) За много лет работы ниразу не видел программера, который бы моделировал ситуацию нехватки памяти для своего кода. Вернее было один раз, в одной конторе нужно было перед сдачей кода провести тестирование при code coverage 99%. Но там была контора CMMI 5-го уровня :)

Комп что-ли перезагружали?

А тут без вариантов. Процесс, который это сделал убит, дескриптор по какой-то причине не освободился. Что еще оставалось делать?

Так после смерти процесса вся используемая им память освобождается же.

В принципе - должна. Но вас никогда не били по рукам за неосвобождение памяти по выходу? Ни один статический анализатор кода вам не ругался про возможную утечку памяти? Мне кажется вы что-то делаете не так.

C нимбом все ок? ;)

Нужно делать свою работу так чтобы стыдно не было. Печально что добросовестная работа редкость.

В принципе - должна. Но вас никогда не били по рукам за неосвобождение памяти по выходу? Ни один статический анализатор кода вам не ругался про возможную утечку памяти? Мне кажется вы что-то делаете не так.

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

А я и не знал, что вы из этих...

У тебя что — мастдайка? Или ты думаешь, что init не освободит память сдохшего процесса?

Под виндой

Проблемы негров шерифа не волнуют. И вообще, к чему эти убогие?

Если писать код - то писать кроссплатформенно

Только если ты — извращенец.

Или ты думаешь, что init не освободит память сдохшего процесса?

Разве это делает init? :) Я всегда считал, что это делает ядро.

Да пофиг, кто делает. Главное, что free надо вызывать только лишь до тех пор, пока ты предполагаешь, что твоя программа работает. Это ж тебе не жаба какая-нибудь...

Но вас никогда не били по рукам за неосвобождение памяти по выходу?

Раньше в Chrome память при выходе намеренно не освобождалась, чтобы ускорить завершение процесса. Как сейчас — не знаю.

Ни один статический анализатор кода вам не ругался про возможную утечку памяти?

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

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

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

P.S. Нет, библиотека под linux. PVS-demo, не под вайном. Проверяю под шиндой, так как код кроссплатформенный и легко компилится под микроволновкой.

о всех возможных местах утечек

http://bash.im/quote/429538

Недавно столкнулся с утечкой a la гейзенбаг. Натурально так — пока смотришь на программу, утечки нет. Перестаёшь смотреть — начинает истекать памятью. Ни cppcheck, ни memcheck valgrind'а ничего не отлавливали. Все возможные утечки... Ха, скажешь тоже.

ни о дровах к свежей вафле, ни о нормальных ФС, ни о UEFI

Пф, ни дров на nvidia в принципе, ни даже если мы говорим о серверной ос, то виртуализации тоже. Короче там ничего нету кроме простого инсталлятора

Сударь, если вы склонны именно так рассматривать, то вы - говно. Это если тезисно и без лишних букв.

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

http://bash.im/quote/429538

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

Все возможные утечки... Ха, скажешь тоже.

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

Натурально так — пока смотришь на программу, утечки нет. Перестаёшь смотреть — начинает истекать памятью.

Valgrind

Абсолютно не согласен с цитатой.

:-)

Valgrind

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

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

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

зачем gdb? открой для себя /proc/sys/vm/overcommit_memory и ulimit. с ulimit цАРЯ уже доказательно опустили в той теме про malloc

Можно об этом по подробнее. Где, кто, как и кого «опустил»?

откуда ты знаешь где и как запущена программа? может там overcommit_memory == 2

откуда ты знаешь где и как запущена программа? может там overcommit_memory == 1

Что ты хотел сказать своим недовыхлопом? Т.е. при == 2 она не упадёт, а при == 0 и == 1 упадёт. Как это спасёт тебя от падения? Т.е. с шансом 33% ты не свалишься? Я уж не говорю о том, что 0 по умолчанию. Т.е. шанс на твоей выхлоп в районе нуля.

Я уж не говорю о том, что юзая == 2 - ты теряешь 0-50% памяти, да и темболее это не спасает.