Здравствуйте, IID, Вы писали:


IID>Вообщем говно этот ваш валгринд. Баунсчекер гораздо функциональнее.

Вот же проблемы у сишников. Отличный пример борьбы с ветряными мельницами, помещу-ка в избранное, буду в срачах managed VS unmanaged приводить.

Здравствуйте, Mazay, Вы писали:

M>Ну с параллельным кодом лучше Интела никто не умеет работать.
Я умею!

Залечил меня проверкой инициализированных данных в куче, а хвалёный Valgring оказывается тривиальные out of bound не умеет детектить! (см. Ограничения Memcheck по ссылке или п.4.6 из Valgrind FAQ)

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

 int Static[5];
 
  int func(void)
  {
    int Stack[5];
 
    Static[5] = 0;  /* Ошибка - существует лишь Static[0] до Static[4], Static[5] выходит за пределы массива */
    Stack [5] = 0;  /* Ошибка - существует лишь Stack[0] до  Stack[4], Stack[5] выходит за пределы массива */
 
    return 0;
  }

Студия в "искоробки" оба случая поймала на этапе компиляции, а случай со стеком ещё и в Runtime. Не говоря уж о том, что всякие баундсчекеры подобные ситуации ещё под досом ловили.

С неинициализированными значениями тоже не всё гладко:

5.3. Memcheck's uninitialised value errors are hard to track down, because they are often reported some time after they are caused. Could Memcheck record a trail of operations to better link the cause to the effect? Or maybe just eagerly report any copies of uninitialised memory values?

Prior to version 3.4.0, the answer was "we don't know how to do it without huge performance penalties". As of 3.4.0, try using the --track-origins=yes option. It will run slower than usual, but will give you extra information about the origin of uninitialised values.

Or if you want to do it the old fashioned way, you can use the client request VALGRIND_CHECK_VALUE_IS_DEFINED to help track these errors down -- work backwards from the point where the uninitialised error occurs, checking suspect values until you find the cause. This requires editing, compiling and re-running your program multiple times, which is a pain, but still easier than debugging the problem without Memcheck's help.

As for eager reporting of copies of uninitialised memory values, this has been suggested multiple times. Unfortunately, almost all programs legitimately copy uninitialised memory values around (because compilers pad structs to preserve alignment) and eager checking leads to hundreds of false positives. Therefore Memcheck does not support eager checking at this time.

Т.е. ловить-то оно ловит, (не сразу правда научилось) но ценой ещё больших тормозов и с охренительной кучей false positive.

Офигенным плюсом валгринда Cyberax называл его эмулируемую природу. Тогда какого хрена возможен этот пункт Valgrind FAQ:

3.2. My (buggy) program dies like this:
valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
or like this:
valgrind: m_mallocfree.c:442 (mk_inuse_bszB): Assertion 'bszB != 0' failed.
or otherwise aborts or crashes in m_mallocfree.c.

If Memcheck (the memory checker) shows any invalid reads, invalid writes or invalid frees in your program, the above may happen. Reason is that your program may trash Valgrind's low-level memory manager, which then dies with the above assertion, or something similar. The cure is to fix your program so that it doesn't do any illegal memory accesses. The above failure will hopefully go away after that.

Вообщем говно этот ваш валгринд. Баунсчекер гораздо функциональнее.

Здравствуйте, IID, Вы писали:

IID>Залечил меня проверкой инициализированных данных в куче, а хвалёный Valgring оказывается тривиальные out of bound не умеет детектить! (см. Ограничения Memcheck по ссылке или п.4.6 из Valgrind FAQ)
Вообще-то, умеет.

"However, the experimental tool Ptrcheck can detect errors like this. Run Valgrind with the --tool=exp-ptrcheck option to try it, but beware that it is not as robust as Memcheck."

IID>Студия в "искоробки" оба случая поймала на этапе компиляции, а случай со стеком ещё и в Runtime. Не говоря уж о том, что всякие баундсчекеры подобные ситуации ещё под досом ловили.
Я же не просто так malloc поставил. Твой пример прекрасно находится статическими анализаторами (Stanford Checker'ом или Coverity). Примеры с динамической памятью — так уже не найдёшь.

IID>Т.е. ловить-то оно ловит, (не сразу правда научилось) но ценой ещё больших тормозов и с охренительной кучей false positive.
На тормоза пофиг, а false positives уже лечатся с помощью отладочной информации. Кроме того, копирование неиницилизированной информации — вообще говоря некорректно и должно правится. В большинстве программ оно уже поправлено, как раз из-за Valgrind'а.

IID>If Memcheck (the memory checker) shows any invalid reads, invalid writes or invalid frees in your program, the above may happen. Reason is that your program may trash Valgrind's low-level memory manager, which then dies with the above assertion, or something similar. The cure is to fix your program so that it doesn't do any illegal memory accesses. The above failure will hopefully go away after that.
Этот менеджер выполняется внутри эмулированного кода, так что опять нет ничего удивительного. Да, его можно сломать, но это диагностируется.

IID>Вообщем говно этот ваш валгринд. Баунсчекер гораздо функциональнее.
Ну да, в нём ничего этого просто банально нет. Соответственно, нет и этих ошибок

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, IID, Вы писали:

IID>>Залечил меня проверкой инициализированных данных в куче, а хвалёный Valgring оказывается тривиальные out of bound не умеет детектить! (см. Ограничения Memcheck по ссылке или п.4.6 из Valgrind FAQ)
C>Вообще-то, умеет.

C>"However, the experimental tool Ptrcheck can detect errors like this. Run Valgrind with the --tool=exp-ptrcheck option to try it, but beware that it is not as robust as Memcheck."

Присоеденюсь к мнению Antikrot-а: у меня всякая экспериментальная хрень вызывает внутреннее отторжение
Неясно что мешало такое ловить изначально. Ведь трансляция в промежуточный байткод и прочее бла-бла-бла.

IID>>Студия в "искоробки" оба случая поймала на этапе компиляции, а случай со стеком ещё и в Runtime. Не говоря уж о том, что всякие баундсчекеры подобные ситуации ещё под досом ловили.
C>Я же не просто так malloc поставил. Твой пример прекрасно находится статическими анализаторами (Stanford Checker'ом или Coverity). Примеры с динамической памятью — так уже не найдёшь.

Boundschecker ловит тем не менее.

IID>>Т.е. ловить-то оно ловит, (не сразу правда научилось) но ценой ещё больших тормозов и с охренительной кучей false positive.
C>На тормоза пофиг, а false positives уже лечатся с помощью отладочной информации. Кроме того, копирование неиницилизированной информации — вообще говоря некорректно и должно правится. В большинстве программ оно уже поправлено, как раз из-за Valgrind'а.
Для POD-ов пофиг на неинициализированное копирование. Копирование это ещё не использование.

IID>>If Memcheck (the memory checker) shows any invalid reads, invalid writes or invalid frees in your program, the above may happen. Reason is that your program may trash Valgrind's low-level memory manager, which then dies with the above assertion, or something similar. The cure is to fix your program so that it doesn't do any illegal memory accesses. The above failure will hopefully go away after that.
C>Этот менеджер выполняется внутри эмулированного кода, так что опять нет ничего удивительного. Да, его можно сломать, но это диагностируется.
Очень плохо, что его можно сломать Что ж это за эмуляция такая криворукая, раз сломать можно что угодно ? Получается что на практике ничего существенного эмуляция не даёт. А в теории, конечно, звучало красиво

IID>>Вообщем говно этот ваш валгринд. Баунсчекер гораздо функциональнее.
C>Ну да, в нём ничего этого просто банально нет. Соответственно, нет и этих ошибок
Не надо ляля, всё необходимое есть, и даже больше Например мониторинг АПИ и COM вызовов. Кстати, дедлоки баундсчекер тоже умеет детектить (в первоначальной ветке кто-то интересовался)

Valgrind не требует специальной компиляции.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Valgrind не требует специальной компиляции.

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

BC требует, зато:
— работает быстрее
— не генерит такое количество false positives, как valgrind.
— нормально находит ошибки индексации массивов (в отличие от того же valgrind)
— умеет находить ошибки в системных и прикладных вызовах.

Знание контекста рулит, а из машинного кода ты немного контекста выгребешь.
Если очень хочется иметь динамическую инструментацию а-ля валгринд (с примерно таким же херовым качеством анализа) есть Intel Parallel Inspector

Ensure application reliability with this memory and threading error checking tool

Intel Parallel Inspector uses dynamic instrumentation that requires no special test builds or compilers, so its easier to test code more often. "

Inspector Brief (PDF). То же самое что и валгринд.

Здравствуйте, IID, Вы писали:

IID>

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

IID> int Static[5];
 
IID>  int func(void)
IID>  {
IID>    int Stack[5];
 
IID>    Static[5] = 0;  /* Ошибка - существует лишь Static[0] до Static[4], Static[5] выходит за пределы массива */
IID>    Stack [5] = 0;  /* Ошибка - существует лишь Stack[0] до  Stack[4], Stack[5] выходит за пределы массива */
 
IID>    return 0;
IID>  }
IID>

IID>Студия в "искоробки" оба случая поймала на этапе компиляции, а случай со стеком ещё и в Runtime. Не говоря уж о том, что всякие баундсчекеры подобные ситуации ещё под досом ловили.

Определённо, такие вещи компиляторы дожны ловить.
Под gcc есть Mudflap, правда это уже рантайм:

*******
mudflap violation 1 (check/write): time=1267802256.754355 ptr=0x700fb0 size=24
pc=0x7f57c948fe91 location=`/home/mazay/prg/test/boundscheck/main.cpp:7 (main)'
      /usr/lib/libmudflap.so.0(__mf_check+0x41) [0x7f57c948fe91]
      ./boundscheck(main+0x9f) [0x400947]
      /lib/libc.so.6(__libc_start_main+0xf4) [0x7f57c89a81c4]
Nearby object 1: checked region begins 0B into and ends 4B after
mudflap object 0x701370: name=`/home/mazay/prg/test/boundscheck/main.cpp:1 int Static [5]'
bounds=[0x700fb0,0x700fc3] size=20 area=static check=0r/3w liveness=3
alloc time=1267802256.754334 pc=0x7f57c948f991
number of nearby objects: 1
*******
mudflap violation 2 (check/write): time=1267802256.754805 ptr=0x7fffc7c48720 size=24
pc=0x7f57c948fe91 location=`/home/mazay/prg/test/boundscheck/main.cpp:8 (main)'
      /usr/lib/libmudflap.so.0(__mf_check+0x41) [0x7f57c948fe91]
      ./boundscheck(main+0x129) [0x4009d1]
      /lib/libc.so.6(__libc_start_main+0xf4) [0x7f57c89a81c4]
Nearby object 1: checked region begins 0B into and ends 4B after
mudflap object 0x701460: name=`/home/mazay/prg/test/boundscheck/main.cpp:5 (main) int Stack [5]'
bounds=[0x7fffc7c48720,0x7fffc7c48733] size=20 area=stack check=0r/3w liveness=3
alloc time=1267802256.754340 pc=0x7f57c948f991
number of nearby objects: 1

Здравствуйте, IID, Вы писали:

IID>Знание контекста рулит, а из машинного кода ты немного контекста выгребешь.
IID>Если очень хочется иметь динамическую инструментацию а-ля валгринд (с примерно таким же херовым качеством анализа) есть Intel Parallel Inspector

Ну с параллельным кодом лучше Интела никто не умеет работать. Жаль только у ихних тулзов половина функционала отваливается на неинтеловских камнях. По крайней мере у VTune точно с этим проблемы были.

Здравствуйте, IID, Вы писали:

IID>Вообщем говно этот ваш валгринд. Баунсчекер гораздо функциональнее.
Поставил, посмотрел как оно работает. Работает оно точно так же как Valgrind — инструментирует машинный код, вставляя проверки.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, IID, Вы писали:

IID>>Вообщем говно этот ваш валгринд. Баунсчекер гораздо функциональнее.
C>Поставил, посмотрел как оно работает. Работает оно точно так же как Valgrind — инструментирует машинный код, вставляя проверки.

Во первых не точно также. Никаких виртуальных эмулирующих машин там нету. Во-вторых он инструментирует код не ПОСЛЕ компиляции, как валгринд (хотя ПОСЛЕ тоже может, но тогда половину ошибок не ловит). А ВО ВРЕМЯ компиляции, подменяя либы на свои.

BoundsChecker can be run in two modes: ActiveCheck, which does not instrument the application, and FinalCheck, which does.
FinalCheck requires an instrumented build and gives a much deeper but more intrusive analysis. It provides all of the detection features of ActiveCheck plus the ability to detect buffer overflows (read and write) and uninitialized memory accesses. It monitors every scope change, pointer and memory usage.

ключевую разницу между BC и valgrind выделил.

Здравствуйте, IID, Вы писали:

C>>Поставил, посмотрел как оно работает. Работает оно точно так же как Valgrind — инструментирует машинный код, вставляя проверки.
IID>Во первых не точно также. Никаких виртуальных эмулирующих машин там нету. Во-вторых он инструментирует код не ПОСЛЕ компиляции, как валгринд (хотя ПОСЛЕ тоже может, но тогда половину ошибок не ловит). А ВО ВРЕМЯ компиляции, подменяя либы на свои.
А разница-то? Его инструментация всё равно ловит меньше багов, чем Valgrind. Те проблемы, которые я перечислил — он таки не ловит.