Здравствуйте, scar, Вы писали:

s> Драсте...
s> Провожу "исследование" памяти процесса под Win98. Всё нормально, всё
s> замечательно и вдруг... Вдруг вижу, что куча с одним и тем же ID
s> расположена в ДВУХ регионах памяти: 0x00400078 — первая "часть" кучи N
s> 0x0C10FFD0 — вторая "часть" кучи N
s>
s> И еще одна такая же "разорвашка"
s> 0x024D0EB0 — первая "часть" кучи K
s> 0x0CC10014 — вторая "часть" кучи K
s>
s> Куч в изучаемом процессе на момент ухода в штопор (из-за абсолютной
s> неожиданности подобной ситуации) моей проги — 57, из них две кучи как бы
s> разбиты на части, которые расположены в разных регионах, и между этими
s> регионами (частями куч) расположены другие кучи, проецируемые файли,
s> стеки и прочие неопознанные регионы памяти. Ну фигня ведь! Разве одна
s> куча (на что указывает ее ID) может иметь блоки, расположенные в разных
s> регионах?
s>
s> Более того, блоки одной из "разорванных" куч попадают в диапазон адресов
s> другой (имеющий другой ID) кучи!!! АААААааааааа!!!!!....... Люди добрые,
s> хорошие и отзывчивые, ну объясните мне, дурню, на что я "напоролся" и
s> как это дело "переварить"?
s>
s> з.ы. Информацию о кучах и блоках в них получал через библиотеку ToolHelp
s> функциями Heap32ListFirst/Next и Heap32First/Next. OC — Win98

Ничего глючного тут нет. А почему собственно куча обязана быть непрерывной? Ты с ней общаешься через интерфейс HeapAlloc / HeapFree и все, что она тебе обязана, это возвращать _непрерывные_ блоки памяти заданного размера. Типичный сценарий: создается куча размера 10М, потом с ней ведется активная работа и она увеличивается еще на 10М. Это увеличение клиент может только заметить по увеличенному времени обслуживания на одном из HeapAlloc. А куча внутри выделила еще один кусок памяти (необязательно непосредственно за первым) и продолжила работу. В одном из последних RSDN была статья про внутреннее устройство Борландовского менеджера памяти из Дельфи и Билдера. Почитай — полезно.

-- Всего хорошего!
-- Alex Alexandrov, e-mail: alex_alexandrov@fromru.com