Bad alloc — Отладка очевидной проблемы с памятью в C ++ — программе
Я работаю с программой, созданной кем-то другим. У меня есть некоторый опыт работы с кодированием, но не так много с кодированием на C ++, поэтому я делаю здесь много «обучения на практике».
Таким образом, программа казалась стабильной, я начал над ней работать, в основном это были небольшие изменения в небольших частях программы.
Недавно я провел оптимизацию производительности, которая также казалась стабильной, но 2 дня назад я что-то изменил и продолжал падать. Поэтому я отменил свои изменения и все еще получил сбои.
Я начал использовать верификатор приложений и глобальные флаги с активированной кучей страниц и проверкой всего связанного с кучей, чтобы выяснить, что вызывало эти проблемы. Поэтому с тех пор отладчик всегда зависал с ошибкой «std :: bad_alloc».
Так как я использовал SVN, я также проверил самую первую версию кода, которую я когда-либо получил, — и я также получаю там bad_alloc-crash.
Теперь мой вопрос: могу ли я быть абсолютно уверен, что этот сбой bad_alloc с включенным Application Verifier является индикатором ошибки внутри программы? При использовании верификатора приложения, сама программа использует много памяти, около 1-1.1 Гб, но больше никогда. Общая системная память используется максимум на 80-90%, поэтому я не думаю, что существует реальная проблема выделения, вызванная слишком малым свободным пространством.
Как вы думаете?
Решение
По умолчанию 32-разрядные процессы в Windows для x86 являются ограничено 2 ГБ адресного пространства (нижняя половина полного адресного пространства).
Если ваша программа выполняет много выделения и освобождения, или если вашей программе требуются большие непрерывные выделения, то да, вполне возможно, что, когда ваша программа использует только 1,1 ГБ рабочего набора, будет недостаточно непрерывного адресного пространства для выделения служб.
(Я работал над большим проектом несколько лет назад, который был сильно ограничен адресным пространством. Для нас было бы обычным «нехватка памяти» с рабочим набором от 1,2 до 1,4 ГБ.)
Page Heap определенно делает эту проблему более острой, поскольку большинство выделений намного, намного больше, чем обычно.
Другие решения
Нет, вы не можете быть абсолютно уверены в чем-либо в произвольной программе на C ++, потому что ваша программа может содержать неопределенное поведение (на самом деле, это почти наверняка так и есть, хотя это может не относиться к рассматриваемой проблеме). Тем не менее, обычная причина std::bad_alloc это невозможность выделить память.
использование станд :: set_new_handler установить обычай new_handlerи поставить точку останова в нем. Если точка останова сработала, то ваша проблема почти наверняка заключается в невозможности выделить память (и состояние программы на этом этапе может быть полезным для отладки вашей проблемы).
Вам следует изучить стек, полученный при сбое двоичного файла с помощью std :: bad_alloc.
Обычно это должно быть потому, что new не удалось выделить память. С помощью стека вы должны знать, сколько памяти было запрошено, и если это странно для вас (например, «выделите 3Go, пожалуйста!»), Тогда вы знаете, где находится ваша ошибка.
При чтении вашего вопроса неясно, но если вы имеете в виду, что процесс использует до 80-90% доступной виртуальной памяти, то, возможно, ваша память фрагментирована, и вы пытаетесь выделить объект слишком большой, чтобы поместиться в оставшиеся свободные маленькие кусочки памяти …
Таким образом, плохое распределение, несмотря на то, что у вашего процесса все еще есть память для игры.
Выполнение поиска в вашем коде, чтобы увидеть, будет ли какая-то часть кода вручную генерировать bad_alloc, также было бы хорошей идеей.