LINUX.ORG.RU

Valgrind 3.8.0

 , , , ,


3

2

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

  • Поддержка свежих дистрибутивов Linux (gcc-4.7, glibc-2.16).
  • Поддержка платформы MIPS32/Linux, в обоих форматах: BE и LE.
  • Начальная поддержка x86/Android.
  • Начальная поддержка MacOSX 10.8.
  • Поддержка инструкций Intel AVX и AES.
  • Поддержка инструкций для десятичных чисел с плавающей запятой для архитектуры POWER.
  • Добавлена поддержка реализаций malloc(), находящихся не в libc.so. Это даёт возможность использовать альтернативные реализации malloc() такие как TCMalloc и JEMalloc при запуске в Memcheck, Massif, DRD, Helgrind.
  • Для инструментов, подменяющих вызовы функции malloc() и ей подобных, добавлена опция --redzone-size=<кол-во байт>, которая позволяет задать размер специальных запретных зон вокруг выделяемых блоков памяти. Чем больше размер этих зон, тем больше шанс поймать выход за границы выделенной памяти.
  • Для инструментов, работающих с потоками, добавлен новый планировщик потоков, основанный на алгоритме round-robin. Этот планировщик является более честным и обеспечивает лучшую отзывчивость интерактивных многопоточных программ, а также даёт лучшую воспроизводимость результатов в Helgrind и DRD.
  • Улучшение производительности при наличии большого количества правил для подавления ошибок.
  • Улучшена поддержка формата Dwarf (поддержка DWARF4 и алгоритма сжатия отладочной информации DWZ).
  • В Memcheck сокращено потребление памяти для программ, выделяющих большое количество блоков памяти.
  • В Memcheck увеличена производительность обнаружения утечек памяти.
  • Во встроенный GDB-сервер добавлено несколько полезных команд для работы с Memcheck.
  • В Memcheck под MacOSX 10.6, 10.7 уменьшено количество ложных срабатываний, которые вызваны особенностями кода, генерируемого LLVM/Clang.
  • Множество других улучшений и исправлений ошибок.

Официальный сайт

>>> Подробности

★★★

Проверено: maxcom ()
Последнее исправление: Silent (всего исправлений: 1)
Ответ на: комментарий от evilface

как в программе могут быть «неинициализированные переменные»

int i;

кстати, пробел разве не нужен?

Не нужен.

mix_mix ★★★★★
()
Ответ на: комментарий от evilface
int *i;
int j;

foobar(i); // foobar получает какое-то неинициализированное говно и умирает в страшных корчах

*i = &j;
anonymous
()
Ответ на: комментарий от anonymous

Иду убиваться об стену:

i = &j;

anonymous
()

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

починил

slackwarrior ★★★★★
()

Прочитал как Virgind — демон, который следит за девственностью...

Доктор, я буду жить?

Hackeridze
()
Ответ на: комментарий от evilface

кстати, пробел разве не нужен?

Единственный нужный пробел стоит на своём месте.

Sadler ★★★
()
Ответ на: комментарий от anonymous

Я же аноним, им хочу и остаться.

Вы на фирме один работаете? Да и потом смысла вас вычислять никакого. Мне правда на изделие взглянуть хотелось.

Свой ассемблер и используется.

Ну, вы правы, от 100001 велосипеда мир не рухнет.

На C++. Без малейшего ООП и уж тем более без OOD. Была одна группка, экспериментировали со скалой и прочей функциональщиной, но их на всякий случай уволили.

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

A-234 ★★★★★
()
Ответ на: комментарий от A-234

Вы вообще программист?

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

Napilnik ★★★★★
()

Valgrind — это инструмент, позволяющий находить в программах недостатки

И зачем оно такое надо? Можно же просто запостить новость на ЛОР и у программы тут же найдется куча недостатков.

spacel0rd
()
Ответ на: комментарий от Napilnik

Я вас умоляю, да в чем разница то? Я вот 90% чужого кода использую, просто отучился велосипеды городить, но анализ корки по моему это вопрос привычки. Кому что удобнее. Тем болле, что valgrind в первую очередь предназначен для поисков утечек памяти и дедлоков, IMHO, с чем анализ дампов помочь мало чем может.

A-234 ★★★★★
()

•В Memcheck под MacOSX 10.6, 10.7 уменьшено количество ложных срабатываний, которые вызваны особенностями кода, генерируемого LLVM/Clang.

хорошо однако

Boy_from_Jungle ★★★★
()
Ответ на: комментарий от A-234

ООП ортогонален функциональщине, императивщине и прочей низкоуровневой фигне. ООП - это такая дебильная методология анализа и проектирования, призывающая все сущности предметной области рассматривать как объекты. Такая «парадигма» просто ну нужна. Правильный пдход в использовании разных абстрактных моделей для разных сущностей. Тысячи их!

А какой язык и какая низкоуровневая семантика будет использована при кодировании - дело вообще десятое.

anonymous
()
Ответ на: комментарий от anonymous

Вообще-то на ООП гонят не «неосиляторы». ООП любят тупые сосунки, которым кажется, что они нашли серебрянную пулю. Те же, кто знает, что существует сотни других семантик, более подходящих под соответствующие задачи, над объектными фанбоями смеются.

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

Поддерживаю. ООП для программиста - как намордник для собаки. Однако, тупость людей давно не удивляет (достаточно рассмотреть какой процент населения берет кредиты в банках). Жаль нельзя свалить на другую планету. Я бы свалил.

PS: Reset, отслеживая твои сообщения очень легко понять кто ты и чего стоишь :)

anonymous
()
Ответ на: комментарий от anonymous

ООП ортогонален функциональщине, императивщине и прочей низкоуровневой фигне. ООП - это такая дебильная методология анализа и проектирования, призывающая все сущности предметной области рассматривать как объекты. Такая «парадигма» просто ну нужна. Правильный пдход в использовании разных абстрактных моделей для разных сущностей. Тысячи их!

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

Снова поддерживаю. Однако подавляющее большинство задач прекрасно решается с использованием простых математических моделей (но вы же неосилили «вышку», правда?). Более сложные случаи я решаю через трансформацию (уже выработались несколько техник трансформации с определенными правилами пользования) вышеуказанных моделей. Эта техника позволяет очень быстро решать задачи любой сложности на языках низкого уровня (в основном Си) таким элегантным путем который не приводит к проблемам среднего программиста которые ноют на форумах в интернете (нет утечек памяти, нет разыменовывания нулевого указателя и прочее).

А какой язык и какая низкоуровневая семантика будет использована при кодировании - дело вообще десятое.

Согласен. После достижения «этого» уровня все ЯП рассматриваются ортогонально (Java/C#, JS, Python оказались в числе наихудших).

anonymous
()
Ответ на: комментарий от anonymous

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

A-234 ★★★★★
()
Ответ на: комментарий от anonymous

Вообще-то на ООП гонят не «неосиляторы». ООП любят тупые сосунки, которым кажется, что они нашли серебрянную пулю. Те же, кто знает, что существует сотни других семантик, более подходящих под соответствующие задачи, над объектными фанбоями смеются.

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

Поддерживаю. ООП для программиста - как намордник для собаки. Однако, тупость людей давно не удивляет (достаточно рассмотреть какой процент населения берет кредиты в банках). Жаль нельзя свалить на другую планету. Я бы свалил.

Семёны - один другого толще.

O02eg ★★★★★
()
Ответ на: комментарий от A-234

суть ООП. Она заключается в абстрагировании данных через интерфейсы

Афаик, это только часть ООП (а именно инкапсуляция).

unsigned ★★★★
()
Ответ на: комментарий от Napilnik

В своих проектах такие баги ищутся элементарно, без кактусов типа гэдэбэ и вальгрина

Ну-ну. Попрогоняй свои проги через valgrind, удивишься. Если, конечно, они не уровня hello, hell.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

Однако подавляющее большинство задач прекрасно решается с использованием простых математических моделей

Вот оно чё, Михалыч. Ну тогда вам сам б-г велел на бэйсике писать.

я решаю через трансформацию

шоэта?

Эта техника позволяет очень быстро решать задачи любой сложности на языках низкого уровня

Ух ты! Тебя, наверное, с руками везде отрывают (руки, похоже, уже оторвали). Что ты забыл на лоре?

PS мой диагноз: микроконтроллеры головного мозга.

true_admin ★★★★★
()
Ответ на: комментарий от A-234

Алан Кей смотрит на тебя, как на говно.

У ООП три столпа, а ты к одному прицепился.

anonymous
()
Ответ на: комментарий от true_admin

Ну-ну. Попрогоняй свои проги через valgrind, удивишься.

В используемом чужом коде есть трудноотлавливаемые ошибки и неидеальное совпадение типов, я это знаю. Информацию, которую выдаёт valgrind, не очень просто приспособить к делу. Нефатальными шероховатостями набить 10кк ошибок легко, откопать среди информационного мусора ценную информацию сложнее.

Napilnik ★★★★★
()
Ответ на: комментарий от A-234

Кстати, Пролог, а точнее Дейталог мы внутри компилятора используем. Это эффективнее чем императивные реализации алгоритмов анализа. Например, на Дейталоге сделаны escape и aliasing analysis.

Пусть кто либо из местных ничтожных фанатиков ООП расскажет, как ту же задачу решать объектно. А я поржу!

anonymous
()
Ответ на: комментарий от anonymous

Я вообще считаю, что это весьма правильный тест. Позволяет держаться подальше от неудачников случайно попавшим товарищам ))

vasily_pupkin ★★★★★
()
Ответ на: комментарий от A-234

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

Ага, конечно. А как же наследование и полиморфизм?

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

Разумный подход но, ваша позиция отчасти быдловата. Я могу на ООП любую задачу решить хоть на Java, хоть на C++. Еще и диаграммы UML могу нарисовать в догонку Dia. Из последнего проекта на «настоящем» ООП я писал на С++ кроссплатформенный расширяемый (привет, интерфейсы) интеллектуальный загрузчик любых (привет, абстракция) типов данных с любых (снова привет) хранилищ. Если рассматривать решение с близорукостью ООП то можно смело утверждать что решение получилось очень элегантное и красивое. Но сам подход в реализации способом представления в виде объекта дал на выходе дибильное решение по другим параметрам. Последующее разноуровневое исследование полученного решения и дальнейшая оценка ООП-парадигмы открыли для меня новый угол рассмотрения и понимания программирования. До этого момента я был ярым сторонником ООП и очень быстро погружался в ее глубины. Фактически, то что вы сейчас тут мне пытаетесь сказать - это уже все пройдено мной. Вы мне ничего нового сказать не можете. Но сказанные мной слова поймут/примут лишь единицы (потому что остальные болеют синдромом 95%).

Успехов.

anonymous
()
Ответ на: комментарий от anonymous

Кстати, Пролог, а точнее Дейталог мы внутри компилятора используем. Это эффективнее чем императивные реализации алгоритмов анализа. Например, на Дейталоге сделаны escape и aliasing analysis.

Пусть кто либо из местных ничтожных фанатиков ООП расскажет, как ту же задачу решать объектно. А я поржу!

Ну далеко же ушел. Пусть ООП фанатики хотя бы про регулярные выражения расскажут. Я поржу за компанию.

anonymous
()
Ответ на: комментарий от anonymous

Однако подавляющее большинство задач прекрасно решается с использованием простых математических моделей (но вы же неосилили «вышку», правда?).

Бгг. А потом эти замечательные люди, вооруженные матмоделями для решения «подавляющего большинства задач», идут и наваливают 100 килобайт неструктурированного говнокода в пределах одного файла, содержащего захардкоженные размеры массивов, утечки памяти, разыменования нулевых указателей и тонны копипаста. Плавали — знаем.

После достижения «этого» уровня все ЯП рассматриваются ортогонально (Java/C#, JS, Python оказались в числе наихудших).

А вот тут, пожалуй, соглашусь.

geekless ★★
()
Ответ на: комментарий от unsigned

Мы парадигму обсуждаем, а не конкретный язык.

Treats datafields as objects manipulated through pre-defined methods only


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

A-234 ★★★★★
()
Последнее исправление: A-234 (всего исправлений: 1)
Ответ на: комментарий от true_admin

Однако подавляющее большинство задач прекрасно решается с использованием простых математических моделей

Вот оно чё, Михалыч. Ну тогда вам сам б-г велел на бэйсике писать.

Я тебя понял. Искренне сочувствую.

я решаю через трансформацию

шоэта?

Вот она, одна из характерных черт ООП-шника - смотреть не дальше объекта\^Wсвоего носа\^Wвыражения. Перечитай сообщение и открой для себя технику контекстной связи. Как разберешься обрати внимание на следующую структуру: «я решаю через трансформацию (...) вышеуказанных моделей». Тебя походу на «вышеуказанных моделей» не хватило, как и не хватило освоить программирование полноценно как инженерную дисциплину (а хватило лишь одеть намордник ООП) ?

Эта техника позволяет очень быстро решать задачи любой сложности на языках низкого уровня

Ух ты! Тебя, наверное, с руками везде отрывают (руки, похоже, уже оторвали). Что ты забыл на лоре?

А тебе зачем?

PS мой диагноз: микроконтроллеры головного мозга.

Дебненький...

anonymous
()
Ответ на: комментарий от geekless

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

Я тоже такое встречал (да и делал такое когда программировал в возрасте околостуденческих лет). Ты поторопился с заявлением. Соотнеси пожалуйста свой опыт с моим вышеуказанным заявлением: «Эта техника позволяет очень быстро решать задачи любой сложности на языках низкого уровня (в основном Си) таким элегантным путем который не приводит к проблемам среднего программиста которые ноют на форумах в интернете (нет утечек памяти, нет разыменовывания нулевого указателя и прочее).»

PS: И думай ...

anonymous
()
Ответ на: комментарий от geekless

А как связаны программисты ООП и регулярки?

Тебе пока не хватает «охвата» дисциплины программирования. Но направление верное - ты уже задался вопросом.

anonymous
()
Ответ на: комментарий от anonymous

Чувак, это похоже на булшит. Давай ты нам дашь ссылки на статьи с «этой техникой», а мы оценим. А то похоже на бред сошедшего с ума социопата, на котором ездит контора-разработчик. Или на тголля

vasily_pupkin ★★★★★
()
Ответ на: комментарий от anonymous

Вы самокритичны, это уже неплохо. Но если у вас что либо не получается может быть причина не в плохом устройстве вселенной? Просто вы приводите абстрактные примеры ни о чем. Я не видел ни вашего техзадания ни реализации, соответственно грамотность ваших подходов могу оценить лишь с ваших слов. Мне тоже доказывали с пеной у рта ценность оператора goto, но я умудряюсь писать код уже много лет без goto вообще, даже в голову не приходит его использовать. А причина в том, что проектируемая архитектура изначально не предполагает ситуаций в которых это может понадобиться. Поэтому извините, но ваш пример мне непонятен.

A-234 ★★★★★
()
Ответ на: комментарий от Napilnik

Информацию, которую выдаёт valgrind, не очень просто приспособить к делу

есть разные ошибки. Уж использование неинициализированных данных или выход за границы массива понять в большинстве случаев просто и 100% случаев говорят о проблемах в коде которые рано или поздно дадут о себе знать.

Нефатальными шероховатостями набить 10кк ошибок легко

1) есть supression filters 2) что-то мне не нравится код на котором 10кк ошибок выдаёт valgrind.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

Тебе пока не хватает «охвата» дисциплины программирования. Но направление верное - ты уже задался вопросом.

Тебе не хватает правильно собранного модуля libastral, определённо.

geekless ★★
()
Ответ на: комментарий от vasily_pupkin

Чувак, это похоже на булшит. Давай ты нам дашь ссылки на статьи с «этой техникой», а мы оценим. А то похоже на бред сошедшего с ума социопата, на котором ездит контора-разработчик. Или на тголля

Забыл что мы в конкуретно-капиталистической среде живем?

anonymous
()
Ответ на: комментарий от anonymous

одна из характерных черт ООП-шника

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

true_admin ★★★★★
()
Ответ на: комментарий от A-234

Просто вы приводите абстрактные примеры ни о чем.

Верно. Туда я и целился.

Я не видел ни вашего техзадания ни реализации, соответственно грамотность ваших подходов могу оценить лишь с ваших слов.

Доверять мне или нет - это ваш выбор. Тут я уже не помогу вам.

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

Goto тоже бывает полезен. Реверсните байткод Java и вы будете удивлены (промолчу про дизассемблированный листинг который пестрит всякими jmp/jz/jne ..).

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

Все нормально. Я не даю готовые ответы.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.