Настройка GFlags для обнаружения повреждения кучи (кроме кучи страницы)?

На одном рабочем сайте наше приложение (*) постоянно дает сбой, но не воспроизводится. Анализ аварийных дампов ясно показывает, что это повреждение кучи: аварии находятся в другом месте, но всегда имеют доступ к нарушениям внутри _1 _ / _ 2_. Win Dbg !analyze -v также сообщает о повреждении кучи.

До сих пор мы пытались запустить приложение с параметр GFlags Куча страницы. Проблема в том, что накладные расходы памяти Page Heap таковы, что приложение больше не будет работать (достигнув предела виртуальной памяти для 32-битного процесса).

Итак, мы не можем использовать Page Heap. Какие другие флаги было бы полезно добавить, чтобы мы либо

  • получить сбой на коррупционном сайте
  • или, по крайней мере, можно получить дополнительную информацию из аварийного дампа, который в конечном итоге будет сгенерирован при падении в HeapFree?

В настоящее время мы пробуем флаги:

в надежде, что следующий аварийный дамп будет содержать дополнительную информацию о том, что пошло не так.

Я рассмотрел эти флаги, но пока их не упомянул:

Одна из проблем, которые у меня (также) есть, заключается в том, что я не уверен, как эти флаги помогают при повреждении памяти. Page Heap, очевидно, вызовет нарушение прав доступа, когда что-то записывает на страницы защиты, но как работают другие флаги?

Должен ли я запускать приложение с помощью Application Verifier, чтобы другие флаги помогли? Или возникнет исключение, когда проверочный код что-то обнаружит?

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


(*): это 32-битное настольное приложение Windows для промышленной автоматизации. В этом случае он работает на Win7 64bit (что отлично работает на многих других сайтах).


person Martin Ba    schedule 26.09.2013    source источник
comment
На самом деле, я считаю, что вариант Page Heap будет вашим лучшим выбором. Если вы еще этого не сделали, вы можете попробовать сделать свой процесс с учетом большого адреса. Надеюсь, у вас будет достаточно памяти для фактического использования флага.   -  person Lieven Keersmaekers    schedule 26.09.2013


Ответы (2)


  1. ИМХО, самый простой способ контролировать всю эту проверку - использовать ApplicationVerifier. У вас идеальный интерфейс, и вы можете поиграть со всеми флагами.
  2. Проверка отсутствия кучи - хороший вариант без особых накладных расходов. Таким образом, если блок кучи плохо изменен и блок освобожден, вы получите перерыв в работе отладчика. Если повреждение происходит рядом с выделением и освобождением блока, это может помочь.
  3. AFAIK «Проверка параметров кучи» - это просто облегченная «проверка кучи при вызове». У меня никогда не было в этом успеха.
  4. Проверка и маркировка хвоста кучи выполняется легко и быстро. Иногда срабатывает у меня.

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

gflags.exe / i Testapp.exe e0

Но: лучший способ найти такие проблемы - полностью использовать Debug-CRT ... если это возможно для вас. Так что, если есть возможность использовать Debug-Version в производственной среде, сделайте это. Внутри Debug-CRT вы снова можете использовать и устанавливать множество флагов ....

person xMRi    schedule 26.09.2013

«Включить кучу страницы» в графическом интерфейсе пользователя gflags включает полную проверку кучи страницы, которая может вызвать описанную вами проблему. Командная строка gflags дает вам больше контроля и позволяет включить стандартную проверку кучи страницы, которая использует меньше памяти, но менее эффективна. Командная строка также предлагает вам возможность использовать сочетание стандартного и полного с помощью параметров / size, / dlls и / address.

Вот параметры, перечисленные в файле справки debugger.chm:

*To enable and configure page heap verification:

    gflags /p /enable ImageFile  [ /full [/backwards] | /random Probability | /size SizeStart SizeEnd | /address AddressStart AddressEnd | /dlls DLL [DLL...] ]  [/debug ["DebuggerCommand"] | /kdebug] [/unaligned] [/notraces] [/fault Rate [TimeOut]] [/leaks] [/protect] [/no_sync] [/no_lock_checks]*
person Marc Sherman    schedule 26.09.2013