Electric Fence, например. Очень пользительно. Или checker.

IMXO дать ее потестировать общественности
Общественность незаставит себя долго ждать :-)

Лучший метод:

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

Что предложит месье взамен це ?

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

>Многое зависит от того, что именно делает программа. 
>Но, можно попытаться сделать ей free. free до запуска - и
>смотришь, сколько места есть, а потом еще один free 
>после выхода и, опять же, смотришь, сколько там места
>свободного остается.

Это как это с помощью free() узнать сколько места есть
и сколько осталось? Очень интересно.

Я не имею в виду Сишную функцию освобождения памяти, а говорю совсем о другом. Набираешь в командной строке консоли free и нажимаешь кнопку Enter. На экране появляется информация о физической оперативной памяти, о кеше системы и о свопе. Смотришь раздел Mem, где в одну строку выводится следующая инфа: Всего памяти, занято памяти, свободно памяти, расшарено памяти, памяти в буферах, памяти в кеше. На 3 последних параметра можно не обращать внимания, вот на параметр free - т.е. количество свободной памяти нужно посмотреть.

>Я не имею в виду Сишную функцию освобождения памяти,
[skip]


1. А ты знаешь, что при завершении процесса
вся память выделенная семейством malloc()/alloc()
освобождается независимо от того хочешь ты этого или нет?
Есть у тебя лики связанные с malloc() или нет, все равно
вся память освободится, кроме случаев работы с shmem(). 

2. Про free(1). А у тебя только один процесс крутится?
И только он память пользует?

По поводу того сколько процессов крутится - я не знаю. Поэтому и сказал раньше "в зависимости от случая". В данном случае все относится к одному процессу. А вот по поводу malloc()/alloc() я, пожалуй с тобой не соглашусь. И вот почему. Как-то был у меня случай - я работал с файловыми потоками через fopen()/fclose() - с обычными файлами на диске. Так вот, эти функции вызывают malloc() и free() для занятия и освобождения места под структуру FILE. И, когда я не всегда вызывал функцию fclose() для закрытия файла, по выходу из программы у меня кушалась память. Т.е. после каждого запуска такой программы я делал free и каждый раз оставалось меньше свободной памяти (причем всегда кратное число). Я не смотрел чему оно было кратно, но факт таков.

>По поводу того сколько процессов крутится - я не знаю. 
>Поэтому и сказал раньше "в зависимости от случая".
ps -ax|wc -l
скажет тебе сколько процессов крутится

>Как-то был у меня случай - я работал с файловыми потоками 
>через fopen()/fclose() - с обычными файлами на диске. Так 
>вот, эти функции вызывают malloc() и free() для занятия и 
>освобождения места под структуру FILE. И, когда я не всегда 
>вызывал функцию fclose() для закрытия файла, по выходу из 
>программы у меня кушалась память. Т.е. после каждого 
>запуска такой программы я делал free и каждый раз 
>оставалось меньше свободной памяти (причем всегда кратное 
>число). Я не смотрел чему оно было кратно, но факт таков.

В секции free уменьшалось, в buffers/cached увеличивалось,
а сумма оставалать той-же. Прочитай в какой-нибудь книжке
про жизненный цикл процесса в Un*x системах и поймешь, что
то, про что ты рассказываешь, не бывает. 

ОК, уговорил, буду больше книжек читать... :)

долой Цэ

Заместо Цэ/ЦэПэПэ и тому подобного отстоя надо юзать языки со сборкой мусора. Иначе проблемы с memory leaks будут просто неизбежны. Я вот для этого дела написал malloc debugger, коий запоминает, в какой строке программы кусок был выделен, и где - освобожден. И даже имея такую информацию многие утечки крайне сложно отловить и исправить...

> надо юзать языки со сборкой мусора. Ты в курсе, что за все надо платить? За легкую жизнь программера расплачивается юзер. Сравни производительность си/ассемблера с явой. Не можешь удержать в голове логику работы своей проги с динамической памятью - учись, повышай квалификацию. Не хочешь / не умеешь - твои проблемы. Нечего на язык валить, если руки кривые.

не используй malloc и иже с ними - вот и весь рецепт используй массивы

Ох и глупенький же ты, однако. Тоже мне, привел Яву в пример языка со сборкой мусора. Дерьмо там, а не GC. Ты на нормальные GC посмотри - в хороших Схемах, Common Lisp-ах, ML-ях. Кстати, даже Жаба с нормальным JIT (e.g. HotSpot) практически не отстает от Цэ. Так что лучше заплатить за потерю 5-10% производительности, чем за сотни лишних человеколет разработки и за неизбежные глюки, повышающие стоимость всего дальнейшего сопровождения проекта. Я так подозреваю, что ты, ламерочек, не писал програм сложнее "Hello, World!", если думаешь, что сможешь удержать в голове "логику работы с динамической памятью". Как ты думаешь, за каким хреном в XFree86 встроенный malloc debugger, и почему они ДО СИХ ПОР (сколько там проект существует?) ловят лики?

Так что помолчал бы про "кривые руки". Тебе самому еще учиться и учиться...

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

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

А если говорить "вообще", то твой наплевизм на производительность довольно распространен нынче. Такие как ты делают программы, которые грузятся по пол-минуты, требуют 128М памяти и P3. Когда заказчик жалуется на низкую скорость работы, ему советуют купить железо помощнее.
А все почему? Раньше программированием занимались те, у кого мозги были для этого приспособлены, а теперь программируют все кому не лень - то есть такие как ты, с кривыми руками, не способные даже понять логику работы своего же кода, не говоря уже о том, чтобы правильно спроектировать программу.

Еще раз - ты глуп как пробка. Поясняю: задача отслеживания ручной работы с динамической памятью практически неформализуема, следовательно, её стоит избегать. Но так как ты не программист (то есть, не математик) - то тебе не понять. Не буду метать бисер перед свиньями, поясняя формально недостатки ручного распределения памяти, по этой теме и так толстые труды написаны.

Второе - ты сам, уродище, признался, что имел в виду "Hello, world!"-ы всякие, так как любой даже не особо крупный проект в одно рыло не осилить, тем более на сволочном, громоздком язычке C/C++.

Про "наплевизм" - а не удавиться ли тебе, уроду сопливому? Ты же явно в школе не доучился, если такое говно выблевываешь. Ты сначала прочитал бы, как GC работают, узнал бы, что стоимость generic malloc/free на порядки больше стоимости аналогичных операций в системе с жестко типизированной памятью и корректной сборкой мусора. Так что удавись, подонок. Ты не имеешь права вообще к компутеру подходить - соплив слишком, и безграмотен. Хочешь перестать быть мразью и превратиться в человека - читай те ссылки, что я тут давал. К примеру, работку про concurrent GC. Там бенчмарки есть, увидев которые ты сдохнешь от бессильной злобы.

И еще - запомни, сопляк: нормальные программисты, вроде меня, к решению любой задачи подходят строго формально, на математическом уровне, без всякой ублюдочной интуитивщины, которую ты тут выблёвываешь зловонными потоками.

Ну и что нормальный программист вроде тебя написал, что ты позволяешь себе поливать всех дерьмом? Если ты настолько крут, продайся в крутую контору MS и с помощью математики исправь баги винды. Заработаешь немерянно денег. Только судя по разговору, ты не программист, а самоучка или выпускник двухнедельных курсов "Как сваять самую крутую программу"

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

>>Хочешь перестать быть мразью и превратиться в человека - читай те >>ссылки, что я тут давал.
Поумерьте свой пыл и подумайте, что бывают люди и поумнее Вас.

>>любой даже не особо крупный проект в одно рыло не осилить, тем >>более на сволочном, громоздком язычке C/C++.
Еще и как осилить. А если у Вас нет такого опыта - не судите по себе самому, а понизьте голос на тон ниже и пообщайтесь с умными людьми на тему того, каков минимум человек для реализации каких бы то ни было громоздких проектов. Кстати, по поводу громоздкого язычка С. Если Вам это не известно, то операционные системы UNIX и даже проглюченные Windows, написаны на чистейшем С. А если Вам по душе Джава и расчеты человеко/часов и конечной стоимости продукта, то напрашивается вывод, что Вы клепаете погремушки типа "учет количества цветных карандашей на складе" для пробитых конторок, потом пихаете им все это, а когда их компы не тянут Ваши программки, заодно пихаете им оптом и "со скидкой" новинки, типа P4 с плоскими мониторами, дабы повысить производительность Вашей системы "контроля цветных карандашей". Если я неправ - поправьте меня и помните, главное - это воспитание. И по тому, как Вы себя здесь ведете, я бы Вас не оценил, как хорошего специалиста ни в программировании, ни в математике. О Вас можно подумать, что Вы просто пробивной господин со средним баллом в дипломе 3.75, но с уймой наглости и напора в запасе.
За сим закругляюсь и прошу Вас не сорить здесь ругательствами. Если же Вам интересен спор о пригодности, достоинствах и недостатках языков программирования (что интересно и мне), все это можно обсудить и в более спокойной обстановке.

PS Если Вам непонятен смысл обозначения ">>", поясняю - это Ваши цитаты.

anonymous - это vsl, который забыл пароль. У него одного стиль такой :-) Не обращайте внимания :-)

2vsl: Если следовать твоей логике, и писать программы на таких языках да и еще с графическим интерфейсом, написанном на скриптовом языке а-ля TK/TCL, то воображаешь, как это все добро будет тормозить? Боюсь, никаких ресурсов не хватит.

Ха. Вот тут народ удивляется, почему я "никого" так резко чмырю. Поясняю: меня бесят недоучки, которые, не потрудившись ни разу бенчмарки самостоятельно проделать, и по теории соответствующие работки почитать, сразу с порога отметают, что, типа "тормозить будет, ресурсы жрать будет...". Почему никто не обратил внимания на моё упоминание о стоимости malloc/free по сравнению с типизированной динамической памятью? Почему никто так и не пошел почитать соответствующую литературу? Складывается впечатление, что все тут собравшиеся защитнички C/C++ - просто убежденные фанатики, знать ничего не желающие. Им достаточно того, что C++ - это типа модно, и все. "Пепси, пейджер, MTV - подключайся!". И еще обижаются, когда я их сопляками называю. Смешно... Я же даже реальные цифры назвал - 5-10% потерь максимум, а как правило и вовсе производительность повышается.

И еще раз - я уже говорил, что в Жабе - херовый GC. Почему гражданин Akan посмел обвинить меня в наличии симпатий к этой ублюдочной технологии? Он что, читать не умеет. Ну так ему, с nobody на пару, надо бы отправиться переучиться заново в средней школе.

vsl

P.S.

А для задач реального времени вообще никакая модель динамической памяти не канает, что с GC, что без него. Так что и альтернативные методы знать надо. Фортран в этом деле хорошо помогает мозги вправить.

vsl

Я вовсе не претендую на крутого программера, и вообще на это звание, но коль скоро сумели сваять такое неплохое ядро на C, то этот язык не так уж плох. Кстати подскажите, я помню кто-то говорил, что есть консольный браузер для манов, чтобы гиперссылки работали? И еще, есть ли способ найти нужную функцию в манах, кроме как man -k "что-то" ?

2vsl. Если выкинуть из твоих постов весь мусор, то останется вот это: ты не способен работать на С/С++/Ассемблере, а другие - могут, и это тебя бесит. Тебе, IMHO, нужно обратиться к хорошему психологу, который поможет тебе избавиться от комплекса неполноценности. Тогда и потребность доказывать всем, что ты самый умный, исчезнет сама собой - ты и так будешь знать, что не хуже других.

На счет консольного броузера - не знаю, а чтобы найти какую-либо функцию в манах можешь попробовать:
find /usr/man | grep func_name , где func_name - имя искомой функции. В случае такого поиска, отобразятся имена файлов мануала(ов), в которых встречается слово func_name

А я вот заинтересовался "правильным" программированием с "правильной сборкой мусора". VSL, кинь ссылку на такой "правильный" язык, желательно с примерами и с ООП. Хотелось еще, что бы там были средства для создания пользовательского интерфейса. И еще. Что ты думаешь про язык ADA95?

Я не vsl, но он тебе скорее всего посоветует ocaml (http://caml.inria.fr) (если ещё сюда зайдёт, разумеется).
Против Ады95 обычно никто ничего конкретного не имеет, но особенно на ней всё равно не пишут. "Никто на ней не пишет, потому что никто на ней не пишет"... Я Аду знаю, и мне она нравится больше, чем C/C++ и Java, но я сколько-нибудь больших программ не писал.

Спасибо за информацию

забавный товарищ этот VSL ... правда надо признать достаточно
хамовитый, в армии наверняка не был, там бы ему давно отбили все и вся
за необоснованное хамство, никто бы даже говорить не стал прямо
сразу бы зарядили в торец. Ну это ладно отступление.
Я работаю сейчас в US (это не для показания крутости, это не велика
проблема для более менее среднего программера уехать). Так вот
проект где я работаю это High Availability Clustering for AIX.
Огромный продукт на котором у IBM огромный бизнес. Написан на
С/C++, Korn shell, Perl, Java. Заказчики у IBM компании типа
Sears это гигантская сеть супермапкетов с многомиллионными продажами
в день. Сбой такого продукта очень дорог и для клиента и для
IBM. Так вот я никогда не видел memory leaks в этом продукте.
Что угодно случается но не утечки. А ведь продукт работает
месяцами. IBM эта одна из немногих компаний, которая инвестирует
большие деньги просто в исследования, к примеру проекты типа
Deep Blue, ну и ряд других напрямую не связанных с компьютерами типа
микроскопов построенных на нестандартных принципах. IBM никогда вообще не пишет софт без тщательного дизайна. Поэтому многие утечки
исключены на этапе проектирования. Так что для меня язык программирования это просто средство и чем проще и надежнее он тем
лучше (С - хороший пример). Это все равно что копать яму и гордится,
что владеешь лопатой. Мой друг, физик, который сейчас занимается прикладной математикой в MIT рассказывал, что к ним недавно приезжал
с лекциями кто-то из пионеров TCP/IP и рассказывал, что Congestion
Avoidance algorithm много раз подвергался критике за простоту, но
более сложные и математически обоснованные алгоритмы проигрывали
в реальных сетях на большом числе экспериментов. В IT зачастую
не работает математический подход.
Ну и в заключение в Linux kernel сделано допущение что все вызовы
функций внутри ядра (и локальные буфера) не превышают 4k. И как
не странно это работает, так же и с памятью ... реально выделения
памяти когда кто-то пишет char a[100000] не происходит а лишь при
заполнении страницы начинают выделяться ядром, поэтому никто не мешает
выделить в 5 раз больше, чем может быть понадобиться. Конечно не всегда можно это предвидеть, но в основном работает.
Кто ясно мысли тот ясно излагает, и язык программирования тут не при чем.
Спасибо за внимание.

To pvs: Я тут давече с mem leak разбирался, кое что можно почитать вот тут http://www.sit.kiev.ua/linux/memory_leaks.shtml, Еще посмотри уже упоминавшийся Electric Fence.

2pvs: хорошую программу можно сделать на любом языке. Весь вопрос в том, сколько это будет стоить (человекочасов, бабок, нервов). Цэ - наименее эффективный в этом смысле язык.

2nobody: На C/C++ я пишу очень давно, и, хоть мне это и не нравится, но пишу много. Лично я умудряюсь обходиться без leak-ов, но это мне дороговато обходится - тащу за собой свой malloc debugger, применяю неродные для идеологии C контейнерные структуры, и т.д. А люди, с которыми я работаю - даже со всем этим моим хозяйством умудряются ошибаться. Ну а на ассемблере я писал, когда ты еще и слова такого, как "компутер" знать не знал - я писал на MACRO11. Так что, сопливое чмо, ты опять с выводами поспешил. Я ругаю не по той причине, что не понимаю, а по совершенно объективным критериям. Ты же, мразь безмозглая, так и не соблаговолил ознакомиться с бенчмарками, просто из своего фанатизьма и безграмотности имеешь наглость гнать на GC. Так что сдохни, подонок, без тебя мир станет лучше.

2solom: из языков с хорошим GC: SML (Moscow, New Jersy), Objective Caml (бывший caml special light), Smalltalk, некоторые реализации языка Scheme (e.g. bigloo), некоторые common lisp-ы (e.g. CLISP). Лучший GC из мною виденных - в objective caml. Он изначально разрабатывался для типизированной модели памяти, многопоточной обработки и низкой латентности. Так же он оказался очень удобным для использования его из C.

С какими GC я не советую связываться - Perl, Python. Там просто полное ублюдство, тормозное и глючное, благодаря такому дерьму потом всякие nobody набираются наглости гнать на GC вообще.

2justme: на Ada пишут, и еще как. До сих пор требование министерства обороны никто не отменял - так что штатовские вояки на Аду подсели прочно и надолго. Так же мне известны некоторые крупные системы на Аде, писанные во Франции и Германии. В общем, для ширпотреба её не юзают, а вот в серьезных задачах она вполне себе уместна.

vsl

"У Абдулы много людей..." то есть, я хотел сказать, у IBM. И людей много, и бабок. Вот они и могут позволить себе писать надежный софт на Цэ/ЦэПеПе.

2vsl: К сожалению, это требование (aka The Ada Mandate) отменили где-то в 97-м году, и сейчас в US DoD забирается C++... А так, конечно, используют её там, где нужна надёжность (даже вроде на некоторых российских самолетах), но, на мой взгляд, она вполне годится и для "обычного" использования. Разве что "хакерством" в ней заниматься трудно.

Много эмоций, мало информации. Жаль...