Automatizálja az alkalmazásblokk-elemek elemzését

Jelenleg, amikor a vállalatok nagy figyelmet fordít a minőségi termékek, instabil programok egyre versenyképesek a piacon. A többszörös terhelés, a regresszió és az egységek tesztelése javítja az alkalmazásokat, de hibák még mindig előfordulnak. Különböző könyvek különböző intelligens megközelítést írásban biztonsági kódot, de megkockáztatom, hogy azt sugallják, hogy az alkalmazás összeomlik, eső és csökkenni fog. Nos, ha a tesztlaborba esnek, akkor is leeshetnek az ügyfelekről. És néha a program összeomlik minden látható ok nélkül, mert a végzetes kombináció körülmények között a tesztelő nem lehet és nem lesz képes megismételni ... By the way, enyhítésére a munkaerő-tesztelők is érdemes gondolkodni - ezek az emberek is, és ezek nehéz kiválasztani a legrövidebb út a kudarchoz lejátszást.

Ugyanakkor azonnal foglal helyet - nem tudom megállapítani a cikkben felsorolt ​​valamennyi összetevő forrásfájlját, mivel az alábbiakban leírt rendszer a cégem tulajdonát képezi.

Tehát, ha még mindig tele van lelkesedéssel - kezdjük!

Hogy kezdődött mindez

Néhány évvel ezelőtt úgy döntöttünk, hogy valamelyik cég harmadik fél könyvtárait használjuk. Csatlakoztatott, ellenőrzött - mindent úgy működött, mint egy óra. De egy esős napon elkezdődött egy betű, majd egyszeri hívások, majd egy hibaüzenetek elkezdődtek, hogy alkalmazásunk instabil. A saját országunkban teszteltük, de nem reprodukáltunk semmit.

Ezután elindultak az ügyfelek felé vezető utak, és felszólítottak arra, hogy leírják a hibás működéshez vezető lépéseket. Egy idő után a bűnösnek találták. Igen, igen, kiderült, hogy ez a könyvtár (de a helyén bárki más is tartozhat, beleértve a miét is). Kiderült, hogy részben nem egyeztethető össze a harmadik féltől származó szoftverekkel. Három hét telt el az eljárás során, életmódban éltünk ...

Ez számomra egy lecke volt. Sajnos ez a leállási program kiderült, hogy az enyém, mivel azonnal foglalkoztam a hibakeresési eszközök létrehozásának problémájával. Nem találtam kész megoldásokat, ezért kezdtem fejleszteni a sajátomat.

terminológia

A cseppdump (a továbbiakban: dump) egy speciális fájl, amelyet a dbghelp.dll könyvtár segítségével gyűjtünk össze, amely az esés idején az alkalmazás vereméről tartalmaz adatokat. Információkat tartalmaz a betöltött modulokról, fogantyúkról, szálakról, memóriahelyről stb. A legtöbb esetben segít az alkalmazás veremének szétszerelésében.

A fájl kiadási verziója (rövidített kiadás) - egy bináris futtatható fájl, amelyet a projekt forráskódjából gyűjtöttek össze. Teljesen különbözik a debug verziótól (például az optimalizálás jelenléte és az adatok inicializálásának hiánya speciális hibakeresési értékekkel). Téves gondolat, hogy a kiadási fájlokat nem lehet hibakeresni. Valójában hibakeresést végezhet, csak alapértelmezés szerint az MS Visual Studio nem tartalmazza a kiadási verziókban lévő karakterek támogatását. A Microsoft dokumentációja szerint a karaktertámogatás engedélyezése kissé növeli a bináris fájlok méretét. Saját tapasztalataimban azonban a fájlméret megemelkedik (és jelentősen). Átlagosan a fájl 100 kilobájtra nő. Nagyobb projekteken ez nem észrevehető, de a kisebb projektek jelentősen megnövelik a méretüket.

A megjelenítési verziók szimbólum generálásának engedélyezéséhez válassza ki a "Programozási adatbázis létrehozása" opciót a "Debug információformátum" opcióhoz (fordító opció / Zi) a fordítóbeállításokban. Ha elfelejtette ezt tenni, a szimbólumfájl nem fog teljesen felépülni, és nem lesz lehetséges hibakeresés.

PDB fájl (karakterfájl vagy csak karakter). A projekt összeállításakor a linker elkészíti a végrehajtható fájlt. A szoftvergyártók régóta különböző módszereket dolgoztak ki a forrásfájlok vonalainak információinak tárolására a szimbólummodulokban. Jelenleg a legelterjedtebb (Microsoftról beszélünk) az EKT 2. verziója (MS Visual Studio 6.0) és az 7B-es PDB (MS Visual Studio 7.0+). Ezek a formátumok képesek arra, hogy kiterjedt információkat szerezzenek a végrehajtható modulokról, beleértve a köteg elemzésére, helyi változók megszerzésére stb.

Windbg. A Microsoft alkalmazások egyik hibakeresője. Az én véleményem az, hogy a kis rendszert a számítógépén nagyon egyszerű a hibakeresés a Visual Studio, de amint az alkalmazás eloszlik és összetett, vagy szükség távoli hibakeresés a nehéz körülmények között, a legkényelmesebb módon - azt windbg. Ismétlem, hogy ez az én személyes véleményem. Ezenkívül a WinDBG számos segédprogramot tartalmaz a hibakeresés megkönnyítésére.

A rendszer általános szerkezete

Először meg kell határoznia a dumpfeldolgozó rendszer funkcióit. A rendszernek képesnek kell lennie:

1. Vegye ki a dump debble (a továbbiakban egyszerűen hulladéklerakók) az ügyfelek és feldolgozza őket.
2. A tesztelés és minőségellenőrzés részlegeinek csepegtetéseit a programozó azonnali hibaüzenettel reagáljon.
3. Végezze el a dump feldolgozást, hogy megtalálja a hibát okozó komponens felelős programozóját, és irányítsa át a dumpot.
4. A hibakereső rendszerrel kapcsolatos hibák rögzítése.
5. Rendelkezni tud a dump feldolgozással a tesztelési osztályon.

Így a rendszernek a következő modulokból kell állnia:

1. Karakter tárolása. Magában foglalja mindkét szimbólumot a szoftverkomponensekből, valamint a külső könyvtárak és alkalmazások szimbólumaiból, beleértve az operációs rendszer részét képező szimbólumokat is.
2. Szerver elemző hulladéklerakók. Szimbólumraktárat használ. A szerver figyeli a bejövő hálózati kapcsolatokat, és rendszeres időközönként ellenőrzi az e-maileket az új hulladéklerakókhoz. A hulladéklerakókat a WinDBG és annak különböző kiterjesztései segítségével értelmezik.
3. Hulladéklerakók gyűjteménye. Összegyűjti az alkalmazás ütközési dumpumait, és továbbítja a Dump Server felé. A helyi (intranet) módban közvetlenül a szerverre küldi őket, és a szerver válaszának eredményétől függően különböző viselkedéseket valósít meg. A távoli (extranet) üzemmódban összegyűjti a bukás dumpot és továbbítja e-mailben.

Most minden összetevőt részletesebben vizsgálunk.

Karakter tárolása

Most bináris fájlok és karakterfájlok vannak. Mi a teendő velük?

Annak megértéséhez, hogy mit kell csinálni velük, meg kell fontolnia egy tipikus alkalmazásfejlesztési szkriptet:

1. A programozó létrehozza az összetevőt.
2. Az összetevő tesztelésre kerül.
3. Az összetevő átkerül az ügyfelekhez.
4. A programozó tovább fejleszti az összetevőt.

Ha a 4. lépés után, az ügyfél egy hiba, a meglévő szimbólumok fájlt (épült átadását követő kliens komponensek) már nem segít, akkor már nem felel meg a kliens komponens. Ezért, amikor az összetevőket az ügyfelekhez továbbítja, a bináris fájl és a szimbólumfájl mentésre kerül. De hol? Ők lehet menteni egy külön mappát a lemezen, de ebben az esetben van szükség, minden egyes alkalommal, hogy megtudja, milyen verzió az alkalmazás számára a költségeket a kliens, majd másolja a fájlokat egy mappát a lemezen, ahol voltak, és használat. Ez a megközelítés kényelmes, ha kevés fájl van. De képzeld el, hogy több összetevőt fejlesztesz. Most képzelj el több tucat elemet. Most pedig képzelj el több tucat elemet egy pár hónapig tartó munkához. És a hibaüzenetek nem csak az ügyfelek (akik korábban ismert változat), hanem a vizsgálati osztályának technikai támogatás, a minőség-ellenőrzési osztály ... Tehát meg kell keresni egy automatizált megoldás.

A Microsoft javasolja egy speciális könyvtár létrehozását a lemezen, amelyet "szimbólumboltnak" neveznek. Ebben a könyvtárban létrejön egy mappák fája az összetevők nevével megegyező nevekkel. Mindegyik mappában vannak olyan almappák, amelyek különleges neveket kapnak a hasító bináris fájlokból. Ez gyors keresést biztosít a szükséges összetevőre vonatkozóan, korlátozott információ alapján (pl. Cseppdump). Egy ilyen mappa létrehozásához speciális segédprogramot használunk, a symstore. Megkeresi a mappákat komponensekkel, és új összetevőket ad hozzá a tárolóhoz, amiből minden ügyfél választhat. Ezenkívül a szabványos fájl keresőmotor kiterjeszthető a saját keresési protokoll végrehajtásával.

Az alábbi példát akkor kaptuk meg, amikor a tesztalkalmazást tiszta gépen elemeztük, ahol eredetileg nem volt szimbólum. Az alábbiakban a helyi lemezen található mappaszerkezetet olvashatjuk le, miután a dokumentumot az Internetről származó karakterek letöltésével elemeztük. Amint a példából is látszik, a WinDBG automatikusan betölti a szükséges könyvtárakat az elemzéshez (a könyvtárak listája és neveik eltérhetnek a számítógépek között az operációs rendszerek verziójától függően).

A Microsoft szoftverek (Visual Studio 6.0, 7.0+, WinDBG) ismerik az ilyen könyvtár formátumát, és kényelmesen dolgozhatnak vele. De felmerül a kérdés: létrehoztál a szimbólum-tárolót, tedd az összetevőket ott, de az esés mélyen az operációs rendszer könyvtáraiba esett, például a kernel32.dll-ben. Nem kell a szimbólumok a Windows operációs rendszer, így nem tudja kivenni a bukása a verem (mivel nincs szimbólum az egyes funkciók, amelyek verem keret van jelen a lerakó, megakadályozza a további elemzés a híváslista), így a teljes lerakó nem fogja megérteni. Azonban van egy speciális szerver az interneten, ami a Microsoft összes karakterének (vagy csaknem mindegyikének) repository-e az elmúlt években. A szabványos karakter keresési protokoll ezzel a szerverrel működik. Például célszerű beállítani Visual Studio, hogy ő keresett szimbólumokat, először meg a számítógépen, akkor a master szerver a cég, akkor, ha a karakterek még mindig nem talált volna pumpált őket a Microsoft szerver. Ugyanakkor a letöltési rendszer elég intelligens ahhoz, hogy átmásolja a letöltött karaktereket az internetről mind a központi kiszolgálóra, mind a személyes gépére.

A dokumentáció szerint ez a rendszer csak egyfelhasználós üzemmódban működik megfelelően, de egyetlen problémánk sem volt többfelhasználós üzemmódban.

Nagy mennyiségű szimbólum tárolással jelentősen lelassult a keresésük, így a Microsoft bevezette a szimbólumkészlet új struktúráját, amelyet nagy mennyiségű adatra optimalizáltak. Az MS Visual Studio 7.0+ és a WinDBG képes dolgozni az új tárolási struktúrával, bár az MS Visual Studio 6.0 nem ismeri ezt a formátumot, ezért el kell döntenie, hogy milyen formátumot fog használni. Ha továbbra is használni szeretné az MS Visual Studio 6.0 programot, akkor a lapos.txt fájlt a szimbólum tároló gyökerében kell elhelyeznie, majd a karakterfát az MS Visual Studio 6.0 formátummal kompatibilis formátumban hozza létre.

A manuális beavatkozást igénylő megoldás azonban hibás. Mindig futtatod ezt a segédprogramot, és akár egy csomó parancssori opcióval, sőt akár minden programozó nyomon követésével, ez egy fárasztó feladat. Ennek a folyamatnak az automatizálása szükséges. Az interneten van egy "CruiseControl" segédprogram. Ez a segédprogram különféle adatforrásokat keres, beleértve a lemezeken található mappákat, a CVS könyvtárakat, a Subversiont stb. és változás esetén minden intézkedést megtesz. Ezt azonban más célokra (automatizálás tesztelésére vagy Fowler folyamatos integrációjára) teszi, de fontos, hogy azt saját célokra használhassa. És számunkra a bináris összetevők archívumát is átvizsgálhatja, ahogyan változik.

• Összegyűjtjük a projektet, elküldjük a CVS-be (ahogy a cégemben is).
• A CruiseControl felébred, észlel egy változást a tárolóba, egy denevérfájlt hív, amely egy symstore-t indít, amely a repository rekurzív átvonulását hajtja végre.

Dump elemző kiszolgáló

Tehát valahogy az ősszel dömpingeltünk. Felmerül a kérdés: "Mit tegyek most vele?".

Először a kezünkkel elemezzük, hogy megértsük, mi lehet tanulni róla. Ehhez futtassa a WinDBG programot, ahol a következő lépéseket tehetjük meg:

Egy kis MFC-alkalmazást írtam, hogy egy gomb kattintásakor a CLSIDFromString funkciót rossz mutatóval hívja, ami miatt az alkalmazás összeomlik. A funkciókód az alábbi: