Detekce neuvolněných bloků

[johnnash]

No zkusim to vypreparovat.
Ale predpokladam, ze tim ze zmenim poradi promenych ve tride by asi nemel _CrtCheckMemory() najednou projit bez chyby kdyz mi to predtim nefungovalo.

EDIT: vypada to ze to asi nebude tak jednoduchy vypreparovat kod, protoze je to dost provazany

Tady je ukazka z tridy

[Marek]

Chyba stále může být u tebe. (a určitě je)

Provázaný kód je jenom fráze používaná pro špatný kód.

Tohle vypadá na dost jednoduchej příklad, to nemůžeš zkrátit na cca 100 řádků a poslat to celé? Neboj, tady nikdo nemá zájem o kopírování tvého kódu.
_________________
AMD Open Source Graphics Driver Developer

[johnnash]

Tak co reknete na tohle?
http://www.stud.fit.vutbr.cz/~xluner00/screen.png
Pokud to neni uplne z obrazku patrne, tak promenna numBorderIndices(4 bajty) lezi na adrese 0x026DE562, za ni je 4x Fence Memory(0xFD).

Kod numBorderIndices = 0; zapise nulu ale na adresu 0x026DE564 cimz samozrejmne porusi Fence Memory. A ted jsem jeste zjistil, ze problem zrejme bude v 2bajtovem unsigned short size . Pokud definuji jako unsigned int tak Visualko zapise na spravnou adresu a nedojde k poruse haldy.

EDIT: kod v assembleru http://www.stud.fit.vutbr.cz/~xluner00/screen2.png je proste spatne, adresa je spatne vypocitana.

[JohnyDog]

[johnnash]

Problem byl skutecne v zarovnani.
V jednom hlavickovem souboru jsem menil zarovnani pres #pragma pack, ale na konci jsem neprovedl navrat do puvodni hodnoty.
Za behu programu se pak lisily velikosti zarovnani od velikosti spocitanych pri staticke analyze.
Pritom by stacilo kdyby si kompilator hlidal poradi vkladanych hlavickovych souboru a propagoval zmenu zarovnani do dalsich.