Доступен (https://sourceforge.net/p/valgrind/mailman/message/35897206/) релиз Valgrind 3.13.0 (http://valgrind.org/), инструментария для отладки работы с памятью, обнаружения утечек памяти и профилирования. Работа Valgrind поддерживается для платформ Linux (X86, AMD64 ARM32, ARM64, PPC32, PPC64BE, PPC64LE, S390X, MIPS32,
MIPS64), Android (ARM, ARM64, MIPS32, X86),Solaris (X86, AMD64) и macOS 10.12 (AMD64).
В новой версии (http://valgrind.org/docs/manual/dist.news.html):
- Проведена работа по обеспечению отладки крупных приложений, потребляющих очень много памяти. Расширен размер кэша. Максимальное число секторов увеличено с 24 до 48, а значение по умолчанию с 16 до 32. Общий размер памяти, который может использовать
Valgrind увеличен с 64 до 128 Гб, т.е. теперь возможна отладка приложений, которым выделено до 60 Гб памяти. Адрес загрузки изменён с 0x3800'0000 на 0x5800'0000, что позволяет загружать крупные исполняемые файлы, размером до 1.2 Гб;- Добавлена поддержка нового представления трассировок стека - "XTree", при котором раскладка памяти оформляется в виде дерева из трассировок стека и привязанных к ним данных. Поддержка XTree добавлена в утилиты Memcheck, Helgrind и Massif, и может применяться для оценки заполнения кучи в приложении. Для управления формированием отчёта добавлены опции "--xtree-memory=none|allocs|full" и "--xtree-memory-file=file". Отчёт также может быть сгенерирован на лету при помощи команды мониторинга xtmemory в gdbserver. XTree может быть сохранён в двух форматах - callgrind (поддерживается в Memcheck) и massif, которые поддерживаются типовыми инструментами визуализации и анализа, такими как callgrind_annotate, KCachegrind и ms_print;
- Обновлён C++ demangler, декодировщик идентификаторов C++ ABI в оригинальный набор исходных идентификаторов кода C++. Добавлена поддержка декодирования ABI-идентификаторов для языка Rust;- Устранена утечка памяти при чтении сжатых файлов debuginfo, которая мешала использованию Valgrind с данными debuginfo, созданными в gcc 7.0 при использовании флага "-gz";
- Добавлена поддержка набора инструкций ISA 3.0B для 64-разрядных процессоров POWER (ppc64);- Для архитектур amd64 и x86 добавлена поддержка CET-префиксов (Control-flow Enforcement Technology) и решены проблемы со сбоем JIT при обработке длинных блоков кода AVX2;
- Для систем arm32 реализованы недостающие инструкции ARMv8;
- Для архитектур arm64, mips64 и mips32 представлена альтернативная реализация инструкций LL (Load-Linked) и SC (Store-Conditional), активируемая при помощи опции "--sim-hints=fallback-llsc" и решающая проблемы с зависаниями в некоторых ситуациях, при использовании реализации, строго соответствующей спецификации LL/SS;
- Улучшена поддержка платформы macOS 10.12;
- На платформе Linux улучшена обработка системного вызова clone в режиме CLONE_VFORK;
- Удалён порт TileGX/Linux, который остался без поддержки и на практике не востребован;
- В Memcheck сокращено число ложных срабатываний при запуске оптимизированного кода, сгенерированного в Clang/LLVM. Добавлена поддержка трассировок xtree (опция "--xtree-memory" и команда 'xtmemory') и рализована опция 'leak_check xtleak' для создания отчёта об утечках в формате xtree;- В Massif добавлена поддержка трассировок xtree (опция "--xtree-memory" и команда 'xtmemory') и значительно сокращено потребления памяти и процессорных ресурсов;
- В Helgrind добавлена поддержка трассировок xtree (опция "--xtree-memory" и команда 'xtmemory') и возможность обработки клиентских запросов VALGRIND_HG_GNAT_DEPENDENT_MASTER_JOIN, востребованных для программ на языке Ada, скомпилированных компилятором gnat.URL: https://sourceforge.net/p/valgrind/mailman/message/35897206/
Новость: https://www.opennet.ru/opennews/art.shtml?num=46721
>>Valgrind
>Устранена утечка памятиЗабавно:)
Я так понимаю, valgrind не пригоден для тестирования самого себя.
Достаточно редкий случай, который не проверили (gcc7 + внешняя сжатая debuginfo) и который проявился только с недавним релизом gcc7.
...а с помощью двух valgrind'ов можно протестить вообще всё! ©
> Я так понимаю, valgrind не пригоден для тестирования самого себя.Пригоден. Для этого в нем есть специальная поддержка.
Интересно а проблемы с AMD FX процессорами исправили уже?vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xCA 0x3 0x1D 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
AMD уже поняло что все эти независимые аффторы компиляторов типа GCC жирно проплаченны Intel-ом,
потому на базе форка LLVM+CLang пилят свой оптимизирующий под AMD компилятор
(правда тоже подонковски - только под самые последние свои модели ЦПУ, но может и на ранних будет профит кто знает) - AOCC{AMD Optimizing C,C++ Compiler}
Лично для меня valgrind помер в тот момент, когда перестал работать без отладочной информации. И ладно бы он требовал ее только для бинарника, но нет же - она требуется для всех используемых бинарником библиотек, начиная от libc и заканчивая иксовыми. Пересобирать всю систему со splitdebug? Нет, спасибо. Могли бы хоть ключик оставить, что ли...
>ля меня valgrind помер в тот моментА что родилось?
Альтернативы-то нет...
Да и что плохого, если он стал просить меньше (сам я валгриндом пользуюсь пару раз перед релизом. Не чаще. Я на плюсах пишу и с памятью проблем нет. А для меня валгринд это в первую очередь проверка на утечки) нюансов.
Google perftools, -fsanitize=address/thread, интеловский инспектор.Альтернатив дофига, на самом деле. Санитайзеры — самое оно, валгринд работает на два порядка медленнее и на порядок грустнее.
> Лично для меня valgrind помер в тот момент, когда перестал работать без
> отладочной информации. И ладно бы он требовал ее только для бинарника,
> но нет же - она требуется для всех используемых бинарником библиотек,
> начиная от libc и заканчивая иксовыми. Пересобирать всю систему со splitdebug?
> Нет, спасибо. Могли бы хоть ключик оставить, что ли...Ну так надо было бы в issue это занести...
А, для меня лично он помер - когда прочёл что поддерживает только никсы.
Для программисткого ПО и особенно как для открытого это даже как то непрофессионально. Можете и это в Issue занеси.
>> Лично для меня valgrind помер в тот момент, когда перестал работать без
>> отладочной информации. И ладно бы он требовал ее только для бинарника,
>> но нет же - она требуется для всех используемых бинарником библиотек,
>> начиная от libc и заканчивая иксовыми. Пересобирать всю систему со splitdebug?
>> Нет, спасибо. Могли бы хоть ключик оставить, что ли...
> Ну так надо было бы в issue это занести...
> А, для меня лично он помер - когда прочёл что поддерживает только
> никсы.
> Для программисткого ПО и особенно как для открытого это даже как то
> непрофессионально. Можете и это в Issue занеси.Советую прочитать про принцип работы valgrind (он очень близок к qemu-uaer). Его сложно портировать на системы с недокументированные ABI ядра OS и загрузчику исполняемых файлов.