Я искал довольно неуловимую ошибку, которую мы видим в приложении в встроенной системе Windows XP.
Мы сузили ошибку до указателя, который должен указывать на блок памяти, вместо этого указывая на NULL. Поскольку память выделяется вызовом malloc (..), который не контролируется, мой инстинкт говорит о том, что malloc не удалось и вернул NULL (хотя мы ищем другие возможности прямо сейчас, такие как условия гонки, которые могут непреднамеренно изменять указатель). Это родное приложение на С++. Крушение было немного более запутанным, чтобы отслеживать эту причину, прежде всего потому, что у нас были только всплывающие аварийные дампы и провал, проявленный в сторонней библиотеке, в которой у нас нет источника, в другом потоке. Веселые времена:)
Мои вопросы сосредоточены на возможности исчерпания памяти. Важно то, что система XP Embedded, в которой мы работали, отключила свой файл.
Итак, у меня есть три вопроса; было бы здорово, если бы кто-нибудь мог прояснить это для меня:
-
В первую очередь, каковы последствия отсутствия файла подкачки? Означает ли это, что, когда куча растет, новая память должна быть найдена и немедленно выделена операционной системой, даже если эти свободные блоки не будут использоваться немедленно? Я видел некоторые анекдотические упоминания об этом, но не мог найти ничего конкретного о том, какие эффекты отключает файл подкачки.
-
Почему Microsoft решила не разрешать кучу с низкой фрагментацией по умолчанию до Windows Vista? Существует ли опасность включения LFH для вашего процесса в Windows XP?
-
Какая разница в WinDbg между "Внешней фрагментацией" и "Фрагментацией виртуальных адресов"?
WinDbg сообщает статистику кучи на затронутой куче следующим образом:
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
04770000 00001002 1621948 94844 1608284 102 6 8068 6 2 L
Virtual address fragmentation 94 % (8068 uncommited ranges)
