Boží tabulka: Visual C++ magic numbers :-)

[Al]

Našel jsem boží tabulku, tak dávám k dobru: http://www.nobugs.org/developer/win32/debug_crt_heap.html#table

Tabulka ukazuje, jaká "magická čísla" dává Visual C++ do paměti před a za alokovaný blok, do neinicializované proměnné a do paměti už uvolněné. Je to příklad pro alokování 8 bajtů. Je jasné, že zkušení kodéři tohle mají v hlavě, ale myslím, že pro řadu lidí je tohleto dobrá pomůcka - doporučuji vytisknout a nalepit vedle monitoru. ))

Mimochodem tyhle ladicí vychytávky Visual C++ byly vždycky snadným argumentem, jak jsem u nás na katedře přesvědčil studenty-začátečníky v C++, že mají zahodit všelijaké frí toto a frí tamto a vzít si pořádný překladač. Plus samozřejmě možnost upravovat kód bez restartu aplikace. Protože zvlášť pro začátečníky s pointerama je nadstandardní podpora ladění životní nutnost.[/img]

[Marek]

Nějaký tabulky s hexa hodnotama jsou hlavně pro ty, co kvalitní prostředí naopak postrádají. Jestli tohle je tvůj argument pro používání Visual C++, tak to na tom to IDE musí být fakt hodně špatně.


_________________
AMD Open Source Graphics Driver Developer

[Crypton]

Ta tabulka se určitě hodí na nízkoúrovňové ladění aplikací v cizích debuggerech (e.g. ollydbg), kde člověk přímo vidí obsah paměti a raw hodnoty proměnných. Jinak je to asi úplně zbytečná záležitost...
_________________

[rezna]

[OndraSej]

Al> Nevím, jaké frí toto a frí tamto používáš ty, ale frí toto a frí tamto co používám já, dokážou vyprodukovat ladící výpisy ve tvaru

[Al]

Takže pro ty, kteří se tu nesnaží jen o flamewar (tak na mě působí hlavně Marek, který nic k věci neuvedl, kromě posměšků a překrucování toho, co jsem já psal), uvádím, jak jsem k tomu došel: V C++ já programuju cca od roku 1994, kdy jsme se to začali učit ve škole. Visual Studio jsem začal používat prakticky výhradně od okamžiku, kdy jsem ho poprvé uviděl, to bylo někdy v roce 1997-98, protože bylo tehdy výrazně lepší než Borland C++, který jsme měli před tím. Výjimkou samozřejmě bylo složité programování GUI aplikací do Windows. Pak jsem v roce 2002 dostal za úkol učit na jedné ostravské fakultě jazyk C a studenti to tam patlali v tehdejším Linuxu, který vůbec nehlídal heap (ani Linux, ani C) a programy studentům fascinujícím způsobem běžely bez pádu i se strašnými pointerovými chybami. Takže z Ostravy znám takové to okřídlené "je to optimalizováno pro Linux" (neboli přeloženo do češtiny: ve Windows to hned padá s access violation, v Linuxu to projde i s tou chybou bez pádu). Potom na katedře v Olomouci jsem zažil kolem roku 2004 studenty, co masově používali obskurní Devc nebo jak se to jmenovalo, velmi primitivní vývojové prostředí bez nějakých ladicích vychytávek. No a proti tomu jsem jim mohl ukázat Visual Studio se spoustou výborných ladicích vychytávek, které třeba dnes v roce 2012 můžeme vidět i u konkurenčních nástrojů, ale před těmi 10-15 lety, ze kdy mám ty svoje zážitky, to jinde moc nebylo. A hlavně ne v tom, co jim ti jejich šílení učitelé doporučovali ve škole. Ono totiž my zkušení najdeme ty triviální chyby hned i se základním debuggerem nebo i jen pohledem do zdrojáku, ale začátečníci ne.

Další moje zkušenost je celkem čerstvá, a proto jsem taky vyhledal právě teď tu tabulku: Pracuju na jednom velkém projektu, který vznikl před 15 lety, je to mišmaš od různých autorů a je to takový propletenec globálních funkcí většinou v Céčku bez tříd. Dělám teď konverzi do Windows, předevčírem mi to tam začalo zmateně padat kvůli nulovému pointeru... samozřejmě chyba byla úplně jinde, než kde se projevovala a díky magickým číslům se objevila za 5 sekund, protože v jednom pointeru bylo 0xfeeefeee. Nicméně já se musím přiznat, že to číslo jsem viděl prvně v živoě, tohle se mi prostě nikdy nepřihodilo, kam moje paměť sahá (v Céčku už teď dělám málo, takže možná jsem na to jen zapomněl). Byla tam prostě uvolněná paměť, která se dál používala a naplnila se kvůli tmu spousta jiných proměnných řadou nesmyslů. Už si nepamatuju, jestil se to tam četlo nebo zapisovalo a co se tam vlastně dělo, ale nějaký ladicí textový výpis, co jste tu ukazovali, by nic neodhalil, protože delete[] se tam volalo jen jednou, jen se ta paměť potom dál používala. Číslo 0xfeeefeee to ale odhalilo. Jedna globální struktura s destruktorem ale bez copy-konstruktoru se tam předávala do jedné funkce hodnotou, místo referencí, takže se v té funkci uvolnila dynamická paměť, ale nevědělo se o tom... Jakmile tu chybu zjistíme, pochopení a oprava je mrknutím oka hotová.

No ale jelikož se tu nejedná o nějaké tahové hry nebo něco takového, ale o realtimové věci, blbě se to ladí nějakými debugovacími výpisy. Taky je často problém ten program restartovat a znovu uvést do stejného stavu, kdy se ta chyba vyskytla, proto je výborné mít tu možnost to bez restartu měnit. Přiznám se, že jsem tak oddaný Visal Studiu, že nevím, které další překladače/debuggery tohle umějí a od kterého roku tuhle funkci mají, ale Visualko to mělo už odedávna a drtilo tím konkurenci. Protože zvlášť ladit něco realtimového s DirectX, kdy si s tím člověk může poladit, změnit funkce a pokračovat bez restartu, je někdy velké plus. Zvlášť potom když se člověk babrá v cizím marastu, co jen od někoho převzal a upravuje.

A protože v Céčku jsem dělal hlavně před rokem 2002, čili posledních 10 let ani moc ne, tak jestli jsem nepostřehl, že místo magického 0xfeeefeee mám ve Visualku nebo jinde nějakou lepší a ještě jednodušší možnost, jak odhalit právě zde uvedenou chybu, tak mi prosím poraďte a poučte mě. (Napadá mě dát si breakpoint na paměťovou buňku, což by mě taky navedlo k původu té chyby, ale bylo by to daleko pracnější a různé obskurní fríí udělátka breakpointy při změně hodnot proměnné taky neumějí.)

[frca]

Mám dojem, že tady někdo neslyšel o valgrindu (nebo možná jen slyšel, a to ještě za hluku projíždějícího vlaku po mostě nad ním).
_________________
www.FRANTICWARE.com

[Tringi]

Jak fascinující je ten rozdíl mezi profesionály a akademiky.
Pro ty první je to rutina, i když iritující; druzí fascinovaně vyrábí dvacetiřádkový elaborát s historickou vsuvkou. Nechceš o tom vydat paper?

Ad realtimový ..."You keep using that word. I do not think it means what you think it means."
_________________
WWW | GitHub | TW

[TeaTime]

VS moc neznám, nějak jsem na něj zanevřel, tak bych se chtěl ujistit, že chápu o čem přesně mluvíš. VS v debug modu nastavuje při free do proměnné hodnotu 0xfeeefeee a to kvůli tomu, aby se tím dalo odhalit double-free a přistupování mimo alokovanou paměť?

Jak přesně funguje to "možnost to bez restartu měnit"? Jakože ti běží "realtime" aplikace, ty jí pauzneš, změníš nějaký kód, necháš to pokračovat a aplikace najednou běží nad novým kódem?

Jo a chtěl jsem se zeptat jak je to s tím realtimem na Windows. Je k tomu potřeba nějaké speciální vydání Windows nebo jak je náročné zkonfigurovat Windows pro realtime?

Dík

[Marek]

[rezna]

fri toto a fri tamto se obcas hodi - ted jsem zacal blbnout s QtCreatorem a neni to vubec spatne - skoda ze aktualni verze se nema rada s CDB z VS, ale tak jedu nad MinGW a GDB a velice dobre

[frca]

Trochu odbočím od tématu: Povedlo se někomu z vás rozchodit debugger nad 64-bitovými binárkami vypadlými z mingw64?
_________________
www.FRANTICWARE.com

[Quiark]

Ano, VS podporuje změnu C++ zdrojáku při debugování - překompiluje a program běží dál. Jmenuje se to Edit & Continue.

Abych udělal Alovi radost, tak tyhle speciální hodnoty v paměti se taky v praxi hodí, člověk pozná, co je ta paměť zač. Na Valgrind to samozřejmě nemá... ale ani ten nejde použít když program nenasytně žere paměť...
_________________
Mám strach

[]semo[]

Díky za tabulku, některý ty věci jsem už věděl, ale přehled je dobrej.

Mimochodem, řadím se k profesionálům. V 2K se debugovalo hodně hodně low-level. Ne každá chyba se dá snadno znovu navodit, proto se používalo spoustu triků, magická čísla nevyjímaje.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[VladR]

Mna len stve, ze prve tri roky (~2001), ked som sa najviac pachtil s pointermi (a nepouzival safeptr), som o tom nevedel. Potom som si vsimol ten pattern a zistil co je CD,DD,FE a uz bolo debugovanie hned o rad jednoduchsie.

Aj nedavno v robote mi to ulahcilo zivot, ked som za 10 min. zistil, ze preco nam to pada.


Preco toto nie je v kazdej dokumentacii a clanku o kodeni vo Visualku ?
Toto by malo byt povinne druha cast kapitoly o pointeroch v kazdej knihe (ak je pro-win orientovana).