C++/Windows: Как сообщить об исключении из памяти (bad_alloc)?

Question

В настоящее время я работаю над системой отчетов об ошибках на основе исключений для приложений Windows MSVC++ (9.0) (т. Е. Структур исключения & типов/наследования, стека вызовов, сообщений об ошибках & и т. Д.).

Мой вопрос сейчас: как правильно сообщать & log out ошибка памяти?

При возникновении этой ошибки, например. как bad_alloc, брошенный оператором new, может быть много «функций» недоступно, в основном в отношении дальнейшего распределения памяти. Как правило, я передавал бы исключение в приложение, если оно было брошено в lib, а затем с помощью сообщений и файлов журнала ошибок для отчета и регистрации. Другой способ (в основном для служб) - использовать журнал событий Windows.
Основная проблема заключается в сборке сообщения об ошибке. Чтобы предоставить некоторую информацию об ошибке, я бы хотел задать статическое сообщение об ошибке (может быть строковым литералом, лучше содержать запись в файле сообщения, затем использовать FormatMessage) и включать некоторую информацию о времени выполнения, такую ​​как стек вызовов.
Функции/методы, необходимые для такого использования либо

• СТЛ (std::string, std::stringstream, std::ofstream)
• ЭЛТ (swprintf_s, fwrite)
• или Win32 API (StackWalk64, MessageBox, FormatMessage, ReportEvent, WriteFile)

Помимо того, что документально на MSDN, все из них более (Win32) или менее (STL) закрыты в Windows, поэтому я не знаю, как они ведут себя при проблемах с низкой памятью.

Просто, чтобы доказать, что может быть проблемы, я написал тривиальное маленькое приложение провоцируя bad_alloc:

int main() 
{ 
    InitErrorReporter(); 

    try 
    { 
     for(int i = 0; i < 0xFFFFFFFF; i++) 
     { 
      for(int j = 0; j < 0xFFFFFFFF; j++) 
      { 
       char* p = new char; 
      } 
     } 
    }catch(bad_alloc& e_b) 
    { 
     ReportError(e_b); 
    } 

    DeinitErrorReporter(); 

    return 0; 
} 

Ран два экземпляра без отладчика прилагается (в конфигурации Release, VS 2008), но «ничего не произошло », то есть коды ошибок из ReportEvent или WriteFile, которые я использовал внутри отчета об ошибках. Затем запустили один экземпляр с одним отладочным отладчиком и попросили сообщить об ошибках один за другим, используя точку останова на линии ReportError. Это отлично работает для экземпляра с прикрепленным отладчиком (правильно зарегистрированный & зарегистрировал ошибку, даже используя проблемы LocalAlloc без проблем)! Но у Taskman было странное поведение, когда до выхода приложения много свободного места, я полагаю, когда вызывается исключение.

Пожалуйста, обратите внимание может быть более чем один процесс [править] и более чем один поток [/ править] отнимает много памяти, поэтому освободив предварительно выделяется куча пространство не является безопасным решением, чтобы избежать низкой среды памяти для процесс, который хочет сообщить об ошибке.

Заранее благодарю вас!

Answer 1

• предварительно выделить буфер (ы) вам нужно
• ссылка статически и использовать _beginthreadex вместо CreateThread (в противном случае, CRT функции могут не) - ИЛИ - реализовать строка CONCAT/I2A себе
• Использование MessageBox (MB_SYSTEMMODAL | MB_OK) MSDN упоминает об этом для представления условий ОЫХ (а некоторые MS блоггер описал такое поведение как задумано: окно сообщения не будет выделять память.)

Logging сложнее, по крайней мере, файл журнала должен быть открыт уже.

Возможно, лучше всего с FILE_FLAG_NO_BUFFERING и FILE_FLAG_WRITE_THROUGH, чтобы избежать попыток буферизации. Первый требует, чтобы записи и буферы памяти были выровнены по сектору (т. Е. Вам нужно запросить GetDiskFreeSpace, выровняйте свой буфер и напишите только на смещения файлов «multiple of sector size» и в блоках, кратных размеру сектора. Я не уверен, что это необходимо или помогает, но общесистемный OOM, где с ошибкой распределения сложно моделировать.

Answer 2

«Освобождение предварительно выделенного пространства кучи ...». Это было именно то, что я подумал прочесть ваш вопрос. Но я думаю, вы можете попробовать. Каждый процесс имеет собственное пространство виртуальной памяти. С другими процессами, требующими большой памяти, это все равно может работать, если весь компьютер работает.

Answer 3

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

В Windows (и других современных операционных системах) каждый процесс имеет собственное адресное пространство (aka memory), отдельное от каждого другого запущенного процесса. И все это отдельно от буквальной ОЗУ в машине. Операционная система виртуализировала адресное пространство процесса от физической памяти.

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

Это также то, как один процесс может выделять больше памяти, чем машина имеет физическую память и все еще работает. Например, программа, работающая на машине с 512 МБ ОЗУ, может по-прежнему выделять 1 ГБ памяти. Windows просто не могла бы сохранить все это в ОЗУ одновременно, а некоторые из них были бы в файле. Но программа не знала.

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

Каждый процесс должен только беспокоиться о себе. И поэтому идея освобождения заранее выделенного фрагмента памяти на самом деле очень жизнеспособна.

Answer 4

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