C++/msvc6 сбои приложения из-за повреждения "кучи", каких-либо подсказок?

Используйте Application Verifier из средств отладки для Windows. . Иногда помогает.

Попробуйте настроить VS для загрузки отладочных символов ОС и убедитесь, что в вашем приложении отключены указатели OMIT FRAME POINTERS. Возможно, трассировка стека будет информативной.

Высокая многопоточность

Давным-давно я обнаружил, что в WinXP существует ограничение на количество потоков на процесс. Мой тестовый фрагмент мог создать только несколько тысяч потоков. Проблема была решена пулом потоков.

РЕДАКТИРОВАТЬ:

Для моих целей достаточно было просто установить флажок «Application Verifier» в gflags.exe. К сожалению, у меня нет опыта работы с другими вариантами. Что касается ограничения количества потоков, тестовый фрагмент был прост:

unsigned __stdcall ThreadProc(LPVOID)
{
  _tprintf(_T("Thread started\n"));
  return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
  while (TRUE)
  {
    unsigned threadId = 0;
    _tprintf(_T("Start thread\n"));
    _beginthreadex( NULL, 0, &ThreadProc, NULL, 0, &threadId);
  }
  return 0;
}

На этот раз я не ждал долго, но количество обработчиков в диспетчере задач увеличивалось очень быстро. Мое приложение в реальном мире получило такой эффект только через 12 часов. Но должен сказать, что проблема заключалась не в сбое, просто не создавались новые потоки.

Вы можете попробовать добавить в свой код вызовы процедур проверки кучи отладки, чтобы увидеть, можете ли вы найти повреждение ближе к источнику (вы используете debug CRT, чтобы отследить эту проблему, верно?):

• http://msdn.microsoft.com/en-us/library/aa271695 (VS.60) .aspx

Ключевым моментом здесь является то, что это происходит только на многопроцессорных машинах (ядра такие же, как и процессоры) Что происходит, когда многопоточная программа выполняется на единственный процессор - это то, что два потока никогда не выполняются одновременно. ОС должна отсекать время для каждого процессора, чтобы моделировать потоки. В многопроцессорной системе несколько потоков могут работать одновременно. Теперь вы, вероятно, получаете доступ к общим ресурсам из разных потоков одновременно. . Эти ресурсы могут быть подключениями к внешним системам и даже глобальными переменными и структурами данных, даже классами синглтонов. К сожалению, теперь у вас возникла одна из самых сложных проблем. Если вы Если вы обнаружите, что память повреждена, вам нужно выяснить, кто еще использует ее в другом потоке, а затем синхронизировать память (Semaphore или CriticalSection). К сожалению, нет простого способа найти проблему.

Вы можете временно установить привязку к процессору, чтобы она работала только на одном процессоре, пока не обнаружите проблему. См. Ссылку http://msdn.microsoft.com/en-us/library/ms684251 (VS.85) .aspx Вот способ установить привязку В Windows XP / Vista / 7 войдите в Affinity, открыв диспетчер задач Windows (CTL + ALT + DEL или щелкните правой кнопкой мыши панель задач), выберите вкладку «Процессы», щелкните правой кнопкой мыши процесс приложения, который вы хотите изолировать, затем выберите «Установить сходство». В диалоговом окне «Соответствие процессору» снимите отметку с ЦП / ядер, которые вам не нужны.Это эффективно изолирует это приложение от выбранных процессоров / ядер, предотвращая охват кэш-памяти и сокращая переключение процессов, а также упрощает вашу способность контролировать выделение процессоров / ядер для нескольких программ.

Можете ли вы опубликовать, какие исключения вы получаете?

Если это какая-то ошибка повреждения памяти, то сбой происходит через некоторое время после повреждения памяти, так что будет сложно отследить первопричину. Вам следует:

1. Поехать (или удаленно войти в систему) в производственную систему, установить Visual Studio, подготовить файлы .pdb и .map (а также символы Windows), подключить отладчик к сборке выпуска и дождаться сбоя. . Хотя, если вы настроите его правильно, вы можете использовать файл минидампа на своей машине разработчика, где у вас уже будет настроено ваше приложение и символы окна. Затем вы можете увидеть, какой из бесплатных вызовов выбрасывается, и попытаться выяснить, какой объект освобождается, чтобы увидеть, не поврежден ли каким-либо образом этот объект и близлежащие объекты в памяти.
2. Как-нибудь найти способ воспроизвести ошибку в вашем офисе, можете ли вы создать достаточно большие объемы, чтобы дублировать то, что делает заказчик?

Опубликованные вами стеки вызовов не выглядят особенно убедительными.

Поскольку вы используете VS 6 с SP6, его STL в порядке.

Можете ли вы сказать, не теряет ли приложение в производственной системе какие-либо ресурсы? В этом может помочь запуск perfmon.

Другое дело, что вы не очень часто вызываете new / delete из разных потоков, не так ли? Я обнаружил, что если вы сделаете это достаточно быстро, вы довольно быстро разобьете свое приложение (так было в XP). Мне пришлось заменить вызовы new / delete в моем приложении на VirtualAlloc (API виртуальной памяти Windows), который отлично сработал для меня. Конечно, STL также может выделять память из кучи.

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

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

Вам нужно определить, какая часть приложения переполнена. Один из способов сделать это - посмотреть на информацию, содержащуюся в переполненном блоке. Если у вас произошел сбой в RtlpCoalesceFreeBlocks, мне кажется, я помню, что один из регистров (@esi) указывает на начало поврежденного блока (во время написания этой статьи я не нахожусь в системе windows и не могу это проверить). Или, если у вас есть дамп, использование команды windbg !heap -a приведет к дампу всей памяти и покажет поврежденные блоки (лучше записать в файл, так как полный листинг кучи может быть длинным). Когда поврежденные блоки известны, их содержимое может помочь идентифицировать код.

Другой помощью может быть включение обратной трассировки стека (с помощью gflags). Это можно сделать в продакшене, так как это легче, чем pageheap. Это добавит некоторую информацию к блокам кучи и может переместить сбой в другое место в вашем приложении, но трассировка стека поможет определить, какой код выделил блоки, которые переполнились.

Используйте профилировщик производительности, который может подключаться к событиям ЦП, например VTune. Установите его в режиме выборки и скажите ему ждать событий, связанных с совместным использованием строки кеша. Они идентифицируются событием HITM из фазы SNOOP.

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

Я не эксперт по архитектуре ЦП или чему-то еще, но я понимаю, что когда ЦП собираются получить доступ к части данных, система проверяет, обращаются ли другие ЦП к той же части данных, это делается. наблюдая за выборкой и записью в память, исходящей от каждого процессора, этот процесс называется отслеживанием.Snooping гарантирует, что если ДВУМЯ или более ЦП имеют одинаковые данные в каждом из своих кешей, дублированные копии данных удаляются при изменении одного из них. Событие HIT-Modified означает, что система обнаружила эту ситуацию и ей пришлось очистить одну из строк кэша ЦП.

См. Этот документ для получения дополнительной информации об использовании VTune таким образом

http://software.intel.com/en-us/articles/using-intel-vtune-performance-analyzer-events-ratios-optimizing-applications /

У меня сейчас нет копии VTune передо мной, так что, возможно, это не сработает, но кажется, что это наименее опасный способ получения некоторых данных. VTune в режиме сэмплирования не должен вызывать особых проблем с производительностью.

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

Что именно это означает: «Мы не можем генерировать символы, потому что мы связываемся с библиотекой, которая не связывается, если мы их используем»? Это кажется странным.