Altap Salamander Support Forums

Otazka:
Su k dispozicii symboly pre WinDBG? (Visual C++/.NET Program Database File pre lepsiu identifikaciu volanych funkcii. *.pdb)

Veřejně zatím k dispozici nejsou, nebyla tu potřeba.

Interně je máme, abychom mohli řešit nahlášené bug reporty.

Budu k dispozicii pre testerov?

Zrovna jsem přemýšlel na tím, že bych navrhnul to samé.

Je s tím spojena nějaká administrativa navíc. Tak nám ještě vysvětlete, k čemu se Vám budou hodit. U programátorů ladících pluginy tomu rozumím, ale v případě testování mi to jasné není.

Nazov funkcie vela napovie a ako tester mozem programatorovi vyrazne ulahcit pracu. Tymto vas nechcem do toho tlacit. Je to cisto len pomocka.

Testujete program v debuggeru nebo kde přijdete do styku s názvy funkcí? Docela mě zajímá metodika, kterou používáte, proto se ptám.

Ked aplikacia spadne, Dr.Watson zvycajne spravi drwtsn32.log + user.dmp file.
"C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson"
Dump file nasledne importujem do WinDBG (CTRL+D) a analyzujem (!analyze -V). V podstate je to bezny postup. V pripade nejasnosti ma WinDBG este dalsie nastroje.

Za celkom prakticke povazujem pozretie si niekolkych videi od marka Russinovich-a "The Case of unexplained" http://www.microsoft.com/emea/spotlight ... ideoid=722 kde popisuje rozne techniky diagnostiky BSOD, padania aplikacii ci mrznutia systemu.

Shlédl jsem tu prezentaci; zajímavé a poučné

Jen nevím, zda znalost názvů interních částí Salamandera pomůže nějak řešit problémy, na které při testování můžeme narazit. Myslím, že Altap má dobře zavedený debug reporting systém a jedinné co můžeme dohledat navíc je, zda problém souvisí s externí komponentou (například můj popis problému se zipfldr.dll), s konkrétním pluginem nebo s jádrem Salamandera.

Nezapomeňte, že při zatuhnutí Salamandera lze druhou instancí prvního Salamandera shodit a vygenerovat bug report (podobně jako Mark Russinovich ve videu shodil Windows pomocí 2x Ctrl+Scroll Lock). Pokud se chcete hrabat v problému více, tak nástroje prezentované Russinovichem poskytují dostatek informací i bez názvů funkcí laděných kompontent. (například pokud se jedná o špatně ošetřené chybové stavy, tak se toto v Process Exploreru ukáže; ...)

Jan Rysavy wrote:Testujete program v debuggeru nebo kde přijdete do styku s názvy funkcí? Docela mě zajímá metodika, kterou používáte, proto se ptám.

Process Monitor umí zobrazit stack u každé zaznamenané operace.

Sám nevím, jestli by to bylo k něčemu dobré, vědět názvy volaných funkcí, ale kdyby jo, tak by se kromě salamandřích taky hodily symboly pro nově vyvíjené pluginy.

Jo a budete se mi smát, až na zásobníku uvidíte toto(*)

CBigVelikost::CallAPI()
CMojeSize::CMojeSize()
CBigVelikost::CBigVelikost()
CMojeSuperWokno::GetVelikost()
CMojeSuperWokno::DoKresleni()
CWoknoBase::OnPaint()
CMojeSuperWokno::OnPaint()

Pokud mám mluvit za sebe, tak třeba některé pády DiskMapy, na které jsem narazil nemají šanci testeři najít ani s názvy funkcí. Pokud uteče nějaký ukazatel, nebo se uvolňuje paměť předčasně, tak se taková chyba projeví později nebo třeba nikdy... To pak chce vzít debuger a hledat, kde k poškození integrity dat došlo.

(Ukázka předčasného "uvolnění prostředků": zkuste v DiskMapě kliknout pravým tlačítkem - otevře se menu - a pak znova kliknout pravým tlačítkem v tom menu... BUM )

(*) Inspirováno skutečnou událostí: Protože se mi nechtělo používat dlouhé slovo Direction, tak v DiskMapě dluohou dobu existoval typ CSmer.

Jsou to zajímavé informace a postupy, děkujeme. Rozmyslíme, co by to pro nás znamenalo, nemáme zatím build / upload mezi-verzí nijak automatizovaný, takže jde o krok navíc. Ale stejně budeme muset pro interní verze DBG symboly držet, což jsme dosud nedělali.

Tak jak jste se rozmysleli (když už existuje EAP)?