Драсте...
Провожу "исследование" памяти процесса под Win98. Всё нормально, всё замечательно и вдруг...
Вдруг вижу, что куча с одним и тем же ID расположена в ДВУХ регионах памяти:
0x00400078 — первая "часть" кучи N
0x0C10FFD0 — вторая "часть" кучи N

И еще одна такая же "разорвашка"
0x024D0EB0 — первая "часть" кучи K
0x0CC10014 — вторая "часть" кучи K

Куч в изучаемом процессе на момент ухода в штопор (из-за абсолютной неожиданности подобной ситуации) моей проги — 57, из них две кучи как бы разбиты на части, которые расположены в разных регионах, и между этими регионами (частями куч) расположены другие кучи, проецируемые файли, стеки и прочие неопознанные регионы памяти.
Ну фигня ведь! Разве одна куча (на что указывает ее ID) может иметь блоки, расположенные в разных регионах?

Более того, блоки одной из "разорванных" куч попадают в диапазон адресов другой (имеющий другой ID) кучи!!! АААААааааааа!!!!!.......
Люди добрые, хорошие и отзывчивые, ну объясните мне, дурню, на что я "напоролся" и как это дело "переварить"?

з.ы. Информацию о кучах и блоках в них получал через библиотеку ToolHelp функциями Heap32ListFirst/Next и Heap32First/Next. OC — Win98

Здравствуйте, 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

>Ничего глючного тут нет. А почему собственно куча обязана быть непрерывной? Ты с ней общаешься через интерфейс HeapAlloc / HeapFree и все, что она тебе обязана, это...
Ну да, ну да... Спасибо огромное! Сам не пойму почему , но после прочтения маленькой тележки всяческой литературы решил, что одна куча обязательно должна располагаться в одном непрерывном регионе. Вот и кричал тут... Сорри за переполох

>В одном из последних RSDN была статья про внутреннее устройство Борландовского менеджера памяти из Дельфи и Билдера. Почитай — полезно.
Поищу обязательно и обязательно же прочту! Спасибо за совет.

И эта... Спасибо еще разочек! //пошел искать статью

З.Ы. s>> Более того, блоки одной из "разорванных" куч попадают в диапазон адресов
s>> другой (имеющий другой ID) кучи!!! АААААааааааа!!!!!.......
Здесь я погорячился — всё еще разок перепроверил и оказалось, что блоки из одной кучи не попадают в адресное пространство другой... Клоун еще...