возможное повреждение кучи (win 32, native C++)

Question

Я работаю с однопотоковым родным приложением C++. Очень сложно воспроизвести ошибку, которую я не могу воспроизвести локально. Я включил полную кучу страниц и отладочную информацию в исполняемом файле, и получил дампы от клиента (который должен использовать приложение много дней, чтобы получить ошибку).

Что клиент сообщает: приложение зависает и никогда не восстанавливается. Его нужно убить из диспетчера задач. Что я вижу из дампов: приложение застревает в бесконечном цикле.

Петля - это переход по двойному связанному списку, который стал циклическим. Существуют признаки повреждения памяти, так как многие члены данных имеют странные значения, например, нулевые совпадения, значения под 0000FFFF или сам связанный список, как сообщается, составляют 300 миллионов +, что не является нормальным.

Единственная другая информация, которую я могу получить из дампов, заключается в том, что операция чтения сокетов не удалась с чтением 0 данных. Это приводит к ходу (теперь циклического) списка.

У меня есть несколько свалок, все висящие в одном и том же бесконечном цикле. Я попытался получить трассировку стека выделения, но! Heap -p -a дает мне «Ошибка ReadMemory для адреса eeddccee Используйте`! Address eeddccee ', чтобы проверить правильность адреса. " для всех адресов, которые я пробовал.

В настоящее время я изучаю предупреждения L4 (за исключением того, что я не знаю, что может быть связано с этим, у меня есть куча C4100, C4511, C4512, которые я не знаю, как исправить, м, в основном фиксируя без проблем как C4244). DebugDiag ничего не нашел, кроме как дать мне «Этот поток не полностью разрешен и может быть или не быть проблемой. Может потребоваться дальнейший анализ этих потоков». на одном потоке.

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

Действительно ли это повреждение памяти? Почему он каждый раз висит в одной структуре? Как я могу найти причину?

Answer 1

Для некоторых закрытий для всех заинтересованных: это был болтающийся указатель. Примерно через год после публикации вопроса клиент изменил аппаратное обеспечение сервера и любезно предоставил нам сервер. Я мог бы легко воспроизвести его с помощью живой отладки на этой машине и найти проблему.

Answer 2

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

Сбой чтения сокета с 0 данными может означать, что разъем закрыт. Возможно, у вас есть проблема с синхронизацией здесь, когда логика закрытия сокетов приводит к параллельному доступу к некоторой общей структуре данных, которая не заблокирована должным образом. Взгляните на код гнезда, чтобы убедиться, что фиксация правильная и водонепроницаемая. Убедитесь, что все возможные коды ошибок правильно обрабатываются в ваших вызовах API сокетов (Winsock, предположительно?). Вы можете быть уверены, что даже малейшее окно для одновременного доступа к контейнеру или «это не может произойти» пути ошибок в конечном итоге попадут в вашу производственную среду. Я знаю, что вы сказали, что приложение однопоточное, но Windows имеет забавную привычку давать вам дополнительные потоки, которые вы не запускали самостоятельно, например, если вы используете службы DLL, которые сами запускают новые потоки.

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

Другим вариантом может быть установка Process Dumper на неисправной машине и указание ему сбросить изображение полной памяти (отлаживаемое в соответствии с стандартным файлом DMB Windbg) при нарушении доступа и выходе процесса. Это может обеспечить лучшую информацию, чем отладка minidump postmortem. Если ваш клиент является кооперативным, он может дать указание создать дамп при возникновении проблемы. Это самое близкое к тому, что вы можете получить в режиме реального времени, не находясь на машине или имеющем удаленный доступ к нему.

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

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

Answer 3

Это может быть почти что угодно.

Если это куча коррупции, попробуйте вставить heap checks в код в стратегических местах. Убедитесь, что ваши двоичные файлы скомпилированы с проверками времени выполнения, которые предлагает компилятор Visual C++. Если возможно, получите тестовый файл от ваших пользователей. Если это невозможно, попробуйте заставить их отлаживать двоичные файлы и/или отлаживать текущее приложение. Исправление предупреждения - хорошая идея, хотя большинство рекомендаций VC на уровне 4 меньше, чем полезно. Сбрасывайте свой код с помощью проверок assert (например). Убедитесь, что все предварительные условия и пост-условия проверены. Убедитесь, что вы действительно обрабатываете каждое возвращаемое значение всех вызовов функций. Также избегайте каких-либо сомнительных практик в коде, например, при использовании стилей C-стиля и типа punning.

Answer 4

Если это какая-то куча коррупции, то Application Verifier может помочь обнаружить это в вашей собственной среде.

full page heap проверка. Если у вашего приложения есть переполнение или переполнение кучи, он будет немедленно пойман.

Если Application Verifier или какой-либо другой инструмент нелегко выявить проблему, то это может привести к выводу , что могло привести к проблеме. Сосредоточьтесь на конкретной проблеме, такой как круговой список. Что может быть причиной этого? Очевидные места для поиска - это все фрагменты кода, которые касаются списка (возможно, что некоторые случайные записи плохой памяти могут вызвать его, но чаще преступник ближе к месту преступления).

Если список доступен только с помощью четко определенных методов, то ваша работа будет проще. Если через глобальный указатель, который могут касаться все, то это сложнее, но все же можно проверить, просматриваете ли вы все ссылки (любой хороший редактор может это сделать). Если вы обнаружите, например, ошибку, которая, возможно, не очищается красиво и правильно заполняет обратную ссылку, тогда вы можете быть на полпути. Затем вы откидываетесь назад. Что может вызвать эту ошибку? И так далее. Выделение «возможной» цепи событий, которая может привести к определенной ситуации, часто может решить такую ​​проблему (и может заставить вас чувствовать себя волшебником в процессе, особенно если это чужая ошибка, которую вы обнаружите).