LINUX.ORG.RU

Valgrind 3.9.0

 ,


1

2

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

  • Поддержка Linux на MIPS64, в обоих форматах: BE и LE.
  • Поддержка MIPS DSP ASE на MIPS32.
  • Поддержка десятичной арифметики с плавающей запятой на s390x.
  • Поддержка инструкций POWER8.
  • Поддержка инструкций Intel AVX2.
  • Поддержка расширений для синхронизации транзакционной памяти на платформе Intel: и RTM, и HLE.
  • Начальная поддержка аппаратной реализации транзакционной памяти на платформе POWER.
  • Улучшена поддержка Mac OS X 10.8.
  • Valgrind больше не отображает в память разделяемые объекты целиком при чтении из них отладочной информации, а читает их небольшими фиксированными порциями.
  • В Memcheck улучшена поддержка векторизованного кода, что должно вести к сокращению ложных сообщений об ошибках.
  • В Memcheck добавлены опции для более точного определения, какие типы утечек памяти отображать, считать ошибками, или подавлять.
  • В Memcheck добавлены эвристики для более точного определения возможных утечек памяти.
  • В Helgrind устранены ложные ошибки, связанные с использованием статически инициализированных мьютексов и условных переменных, а также с таймаутом в функции pthread_cond_waits().
  • Добавлен новый экспериментальный информационный сервер для дистанционной отладки. Valgrind может считывать отладочную информацию с другой машины, где лежат объекты с отладочной информацией. Это необходимо при запуске Valgrind'а на устройствах с ограниченными ресурсами, таких как телефоны и планшеты.
  • Улучшен монитор gdb-сервера, добавлены новые команды.
  • Максимальное количество памяти, с которой может работать Valgrind на 64-битных системах, увеличено до 64 ГБ, что должно позволить запускать под Memcheck'ом приложения, требующие до 35 ГБ памяти.

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

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

★★★

Проверено: Shaman007 ()
Последнее исправление: Wizard_ (всего исправлений: 3)

В Memcheck добавлены опции для болле точного...

ziemin ★★
()

Улучшена поддержка Mac OS X 10.8.

Стого говоря, её не было. Всё заканчивалось примерно так:

==27262== Memcheck, a memory error detector
==27262== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==27262== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==27262== Command: ./a.out
==27262== 
==27262== WARNING: Support on MacOS 10.8 is experimental and mostly broken.
==27262== WARNING: Expect incorrect results, assertions and crashes.
==27262== WARNING: In particular, Memcheck on 32-bit programs will fail to
==27262== WARNING: detect any errors associated with heap-allocated data.
==27262== 
--27262-- ./a.out:
--27262-- dSYM directory is missing; consider using --dsymutil=yes
UNKNOWN workq_ops option 32
UNKNOWN workq_ops option 32

valgrind: m_syswrap/syswrap-amd64-darwin.c:460 (void wqthread_hijack(Addr, Addr, Addr, Addr, Int, Addr)): Assertion 'VG_(is_valid_tid)(tid)' failed.
==27262==    at 0x238037DC7: ???
==27262==    by 0x238037D7B: ???
==27262==    by 0x2380C1BEE: ???

<...>

==27262==    by 0x7FFF5FC01FBF: dyld::initializeMainExecutable() (in /usr/lib/dyld)
==27262==    by 0x7FFF5FC05B03: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)
==27262==    by 0x7FFF5FC01396: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in /usr/lib/dyld)
==27262==    by 0x7FFF5FC0105D: _dyld_start (in /usr/lib/dyld)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
asaw ★★★★★
()

Обновление нужно для нужно. Впрочем, оно и так неплохо справляется, на десктопе.

queen3 ★★★★★
()

Нужно, ура!

Использую наперевес с gcc -Wall -Wextra ..., gdb и мозгом.

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

А до того была OS X 10.8. (Именно так пишется, начиная с OS X 10.7 включительно).

К чему ваш комметарий?

andreyu ★★★★★
()

Падонки! Вместо того чтобы пилить унылый memcheck, лучше бы libvex отдельным модулем сделали, и документацию актуальную написали бы!

Такими темпами, валгринд тупо загнется...

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

clang с встроенными санитайзерами уже уделывает его по всем параметрам

Ага... В этом-то все и дело! Только полноценный дизассемблер еще не допилили. Как только, валгринд можно будет выкидывать на помойку. Что очень и очень печально по многим причинам.

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

clang с встроенными санитайзерами уже уделывает его по всем параметрам

4.2, memcheck умеет memory sanitizer и address sanitizer одновременно (если их скрестить в clang, оверхед получится почти как у valgrind), для остальных инструментов замены нет

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

Как только, валгринд можно будет выкидывать на помойку.

Профилировать CPU и память чем будешь? Эквивалентной замены для callgrind и massif нет

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

лучше бы libvex отдельным модулем сделали, и документацию актуальную написали бы

или заинтегрировались бы с qemu

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

clang sanitazers. Компилируешь программу со спец флагами, запускаешь, смотришь вывод. Кстати, таким образом в гугле тестируют хром.

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

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

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

В чем состоит недоделанность и экпериментальность и где оно должно поддерживаться?

Идея хорошая, но валгринд выглядит пока предпочтительней.

гугл с тобой не согласен

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

callgrind показывает только _количество_ вызовов

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

gprof

Показывает вообще неизвестно что, использовать имеет смысл только на платформе, где ничего другого вообще нет. Если использовать sample-based профилирование (и мириться со статичстичностью результатов), тогда oprofile.

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

Не на порядки, а всего-то раз в десять. При этом memory sanitizer довольно стремная штука, требующая виртуальную машину как и валгринд (или полную перекомпиляцию всего начиная с libc)

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

Ты неосилятор gprof'a. Я им всегда находил узкие места, а вот callgrind мне всегда показывал лишь «неизвестно что», имеющее мало общего с реальностью.

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от annulen

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

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

По ходу, ты либо брезгуешь «гламурным интерфейсом», позволяющим достать из одного замера тонны информации, либо твои боттлнеки были не по CPU

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

http://clang.llvm.org/docs/MemorySanitizer.html

«MemorySanitizer requires that all program code is instrumented. This also includes any libraries that the program depends on, even libc. Failing to achieve this may result in false UMR reports.

Full MemorySanitizer instrumentation is very difficult to achieve. To make it easier, MemorySanitizer runtime library includes 70+ interceptors for the most common libc functions. They make it possible to run MemorySanitizer-instrumented programs linked with uninstrumented libc. For example, the authors were able to bootstrap MemorySanitizer-instrumented Clang compiler by linking it with self-built instrumented libcxx (as a replacement for libstdc++).

In the case when rebuilding all program dependencies with MemorySanitizer is problematic, an experimental MSanDR tool can be used. It is a DynamoRio-based tool that uses dynamic instrumentation to avoid false positives due to uninstrumented code. The tool simply marks memory from instrumented libraries as fully initialized. See http://code.google.com/p/memory-sanitizer/wiki/Running#Running_with_the_dynam... for more information.»

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

А, еще у callgrind есть офигенная возможность сделать замер между двумя точками в коде.

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

CPU это слишком примитивно

Оптимизировать алгоритмы - самое то.

Если дело не в CPU, тогда от callgrind пользы мало. В такой ситуации я использую oprofile. У gprof недостатков настолько много, что непонятно, зачем он вообще нужен.

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

Инструментарий в любом случае не ловит 100% ошибок. Кстати, у valgrind еще и с чувствительностью хуже, например, он не ловит выход за пределы массива на стеке и отсутствие return у не-void функций.

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

Когда программа уже падает опции компиляции обычно проверяешь в последнюю очередь :) А вообще верно.

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

При отсутствии return в не-void-функции любой нормальный компилятор даже без специальных опций как минимум warning выдаст. Или у вас там на такие вещи внимание не обращают, предпочитая принцип «компилируется и ладно»?

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

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

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

gprof уныл, да! Но почему забыли Vtune и CodeAnalyst?

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

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

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

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

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

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

пользовался callgrind - увидел там только количество вызовов, это вызовы функций? разве это полезно? нужно нужно ведь время в функции либо количество инструкций
пользовался oprofile - он почему-то выдавал очень малое количество «единиц» на функцию - может слишком малое время теста? сложно что-то оценить

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

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

Та я знаю, код надо вообще писать без ошибок )

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

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

Та я знаю, код надо вообще писать без ошибок )

Без ошибок не получится, если это не hello world, конечно. :) Но в чём проблема писать код, не заставляющий компилятор выплёвывать кучу предупреждений?

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

Но в чём проблема писать код, не заставляющий компилятор выплёвывать кучу предупреждений?

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

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

пользовался callgrind - увидел там только количество вызовов, это вызовы функций?

А куда ты смотрел? Вот, например, первый попавшийся скриншот:

http://trbs.net/media/misc/django-runprofileserver-kcachegrind-full.jpg

То, что тебе нужно, находится в колонках Incl. и Self (если выключить проценты, будет число инструкций).

разве это полезно?

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

пользовался oprofile - он почему-то выдавал очень малое количество «единиц» на функцию - может слишком малое время теста?

Возможно. Результаты oprofile (в отличие от callgrind) носят статистический характер, поэтому размер выборки важен.

P.S. Надеюсь, никто из присутствующих не полагает наивно, что gprof показывает время, проведенное в данной функции :)

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

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

Wut?

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