интересен проблем с паметта

днес наблюдавах интересен ефект, доста смущаващ, но засега не съм го изкарвал в отделна програма за проверка.
става въпрос за следното - използвам GlobalLock за да си направя paste, обаче нещо гърми. зачепках се и открих проблема - между GlobalLock и GlobalUnlock викам една функция на IDirect3DDevice8 - CreateVertexBuffer, която трябва да ми върне указател СОЧЕЩ ДОСТА ТЛЪСТ ОБЕКТ. това което всъщност е правело проблема е че тяа функция ми дава указател само с няколко байта преди този който GlobalLock връща. картинката е ясна - обекта създаден от CreateVertexBuffer се настанява върху глобалната ми памет, дето уж трябва да е заета. аз разбира се реших проблема (копирах глобалната памет веднага след заключването и), но не това е важното. номера е че операционната система допуска конфликт в паметта, ако няма нещо което не знам. ако имате идеи защо става така...
наблюдавах ефекта под 98,

В MSDN пише, че GlobalLock служи за заключване на вече заделена памет (заделена чрез GlobalAlloc). Та ти каква памет се опитваш да заключваш?

добре знам че е така.
конкретно случая за който говоря е заключване на паметта при paste. разбира се алокирането е извършено при copy. паметта си е типтоп, проверих я все пак със GlobalSize, но няма несъответствия.

хмхм..
предполагам, че самият обект създаден от IDirect3DDevice8::CreateVertexBuffer не е толкова голям, а паметта която му е необходима за "vertex buffer" я държи като handle или указател някъде в себе си.

още че повече, (несъм специалист в DirectX, но видях), че при точно тази функция има параметър (D3DPOOL) за това къде да се разположи новосъздаденият ресурс - тоест ако се метне някъде в offscreen видео паметта, със сигурност не се закача heap паметтa, освен за самия обект (разните му там поинтери, променливи за състояние, reference counting), но без тлъстия буфер.
та думата ми е, че е много малко вероятно операционната система да е оплела нещата. тия работи като memory managementa се тестват до припадък.
този ефект наблюдава ли се под win2000/xp?
GlobalAlloc/Free функциите по принцип са стъпили на RtlAllocateHeap/RtlFreeHeap + табличка на handle-тата (за която се ползва RtlAllocateHandle), което значи че можеш да ползваш gflags.exe примерно и разбира се да викаш HeapValidate() (RtlValidateHeap) или
RtlValidateProcessHeaps(), около кода в който се случва проблема. Също така, ако GlobalAlloc-ът не е с флаг GMEM_MOVEABLE - дирекно се препраща към RtlAllocateHeap, без да се закача табличката с handle-тата (щото няма смисъл); тъй че може да се пробва така + пак check-вания на heap-а.

естественонай-добре е да се отдели "ефекта" в отделна програмка за да се изследва (ако разбира се изобщо се прояви).
и също може да се опита с някоя чудесия като BoundsChecker например, да се види какво ще каже...

(бележка: по горните неща за паметта се отнасят за win2000/xp, вин98 не съм пипвал от години, не съм се ровил много в него, тъй че там реализацията може да е съвсем различна).

да, и аз предполагам че обекта който се създава не е голям, обаче факта че при наблюдение debug точно функцията CreateVertexBuffer предизвиква промяна в данните сочени от поинтера взет със GobalAlloc. всъщност ще взема да пробвам след малко да изолирам ефекта в демонстрационна програма. за съжаление за да ползвам Direct3D трябва тлъста инициализация, така че няма да може да се получи малък компактен и убедителен код.
а иначе ефекта не съм го пробвал под 2000, а трябва, това би дало информация. аз не смея да твърдя със сигурност че е нещо в мениджмънта на паметта, защото както ти каза тия неща ги тестват до побъркване.