Mit előlegként
már megkaptál, ne várd a
végelszámolásnál.
Ahogy minden szoftverfejlesztőt, most éppen engem is utolért a végzet. Egy régebben C#-ban mások által megírt kódban kellett ad-hoc javítgatni egyet s mást, többek között egy el nem kapott exceptiont kellett valahogyan ártalmatlanná tenni. A probléma gyökere egy aszinkron függvényhívás mélyén rejtőzött, ahol az XML értelemző próbálta egy exceptionben a tudomásunkra hozni nemtetszését számunkra megfejthetetlen okból.
A rövidítés
kényelmes ugyan, csakhogy
máshová vezet.
Gyerekkoromban járta az a vicc, miszerint
- Mi a különbség a hullámvasút és a női mell között?
- Semmi! Mindkettő a gyerekeknek készült, de a felnőttek élvezik.
Nos, hasonlóan sikeres és de félreértelmezett találmánya volt a világnak a linuxos procfile rendszer.
Már elég régóta írok hibalerírásokat haikukban, de most rajtakaptam egy fickót, aki kódirás közben sem tud ellenállni a vágynak. Íme az inkriminált comment egy Java kódban, hála a stackoverflow.com zseniális kommentgyűjteményének, amiért viszont hála Sopánka76-nak aki a figyelmembe ajánlotta.
Elöl állsz végre
egy sorban? Lendületből
előz a másik.
Érdekes túlkínálati válság alakult ki Kínában a 90-es években. A termelés hihetetlen iramban nőtt, a fizetőképes kereslet is jelentősen növekedett, egyetlen dolog hiányzott ahhoz hogy a belső piac hatalmas ütemben bővülni kezdjen. A szabadidő. Ugyanis a feszített munkatempó, a hatnapos munkahét és hivatalos ünnepek hiánya miatt a dolgozók nem tudták elkölteni amúgy szépen gyarapodó megtakarításaikat. A párt persze lépett és 1995-ben bevezették az ötnapos munkahetet, majd 2000-ben az arany hetek néven ismert 3 egyhetes nemzeti ünnepet.
No valami hasonló állapotot sikerült előállítani nemrég egy rosszul sikerült consumer/producer implementációval nem olyan régen.
Csúf viszály kél, ha
változódon megannyi
proci osztozik.
Nemrégiben egy kisebb projekt keretében egy meglévő egyszálú linux kernel modult kellett átalakítani többszálúvá, mert egy szálon már nem tudott megfelelő teljesíményt nyújtani. A jelenlegi állapotban egy 8 processzoros gépen, 8 konkurrens szálon fut nagyjából ugyanaz az adatfeldolgozó rutin. A szálak működését befolyásoló tényezők egy közös memóraiterületen vannak tárolva és akár működés közben is változhatnak. Ezeket sikerült megfelelő read/write spinlockokkal úgy zárolni, hogy a modul teljesítménye az eredeti egyszálas verzió többszörösére nőtt. Ezzel a feladat nagyjából megoldottnak volt tekinthető, ám egy kóbor ötlettől vezérelve kitaláltuk, hogy jó lenne statisztikákat kapni futás közben arról, hogy mennyi és milyen típusú adatot dolgoztunk fel. Mindössze néhány egyszerű számlálóról volt szó, pillanatok alatt kész is lett. Csakhogy döbbenten tapasztaltuk, annyira gyorsan dolgozik a modul, hogy nem győzi számolni az elvégzett munkát.
A sajt mérete
nem csak a sajttól, de a
lyukaktól is függ.
Egy szoftvert próbálunk már egy darab ideje 32 bites linux kernelről átírni 64 bitesre. Már túl voltunk az első egészen triviális szívásokon, mint pl a long/int, pointerek és egyebek hosszváltozása, de a rendszer csak nem akart összeállni. Egy idő után egy structra terelődött a gyanú, amit egy memcpy-val másoltunk át egy bitfolyamba és majd ott bitenként kezdtük elemezni. Míg 32 bitesek voltak az alkalmazások az átmásolt tartalom így nézett ki
struct akarmi {
int i; // 4 byte
long j; // 4 byte
}; /* sizeof (struct bar) = 8 bytes */
Elfeledkeztünk viszont arról, hogy mikor áttértünk 64 bitre nem csak a long hossza változott meg 64 bitre, hanem az alignment is. Ettől kezdve tehát így nézett ki a struktúra
struct akarmi {
int i; // 4 byte
// 4 byte padding
long j; // 8 byte
}; /* sizeof (struct bar) = 16 bytes */
Amikor átmásolás után bitenként próbáltuk a struktúra értékét értelmezni akkor jött a végzetes csapás, mert beleolvastunk a paddingbe a long értéke helyett.
Itt van egy remek kis cikk a Suntól, hogy mire érdemes figyelni a 32/64 bites áttéréskor és milyen segédeszközök vannak, emitt meg egy a Microsofttól. Érdemes elolvasni őket mielőtt fejjel menne az ember a falnak, mert vannak a listán kevésbé triviálisak is.
A titokról a
fátyol fellebben. Alant
új fátyol lapul.
Sokszor az ember egészen kis probléma megoldásakor szalad bele jókora pofonba. Nálam most egy verziószám kiírása volt az apropó, a feladat az volt, hogy egy végrehajtható kiírja a verziószámát, mindezt C-ben. A verzió főverzió.mellékverzió.inkremens (pl "8.5.3") formátumban kellett volna megjelenjen és a környezet miatt külön-külön volt egy-egy define-nal beállítva, imígyen#define VERSION_MAJOR 8
#define VERSION_MINOR 5
#define VERSION_INCREMENT 3
Namár most ezt kellett volna egy "8.5.3"
értékű stringgé konvertálni. Az első próbálkozások váltakozva eredményeztek "VERSION_MAJOR.VERSION_MINOR.VERSION_INCREMENT"szerű kiírásokat és válogatott fordítási hibákat. Hosszas guglizás után a precompiler # operátor használata (és a precompiler működésének megértése) jelentette a megoldást. Ugyanis a precompiler "matrjoska baba"-szerűen kezdi el értelmezni a makrókat és a # operátorral rá lehet erőltetni egy makró feloldását. Ha csak a makró neve áll ott akkor szimplán behelyettesíti az nevét, ha #név áll ott akkor fel is fejti a makrót. Íme a győztes megoldás:
#define VERSION VERSION_MAJOR.VERSION_MINOR.VERSION_INCREMENTKissé bonyolult, de működik. Ha valakit mélyebben is érdekel a probléma, jó leírást találhat itt, akár bonyolultabb makrók irásához is.
#define VERSION_STRING_(X) #X
#define VERSION_STRING(X) VERSION_STRING_(X)
static const char* version = VERSION_STRING(VERSION);
A letűnt idők
szoftvere zabálja a
jövő fáljait.
Ha automatikusan újrainduló windows szervízeket futtatsz, mindig légy óvatos, hogyan állítod le és cseréled ki a szervízhez tartozó végrehajthatókat. Ne ess kísértésbe, hogy task managerből lődd ki a végrehajthatót, különben úgy jársz mint mi, újraéled egy régebbi verzió és megzabálja az újabb futáshoz előkészített input file-okat.A szervízes használat esetén nagy körültekintést igényel a végrehajtható visszatérési értékeinek megtervezése, hogy valóban csak akkor induljon újra, ha arra szükség van.
A haiku projekt fertőz!
"Jonathan Schwartz, az Oracle kezébe került Sun Microsystems egykori vezérigazgatója legutóbb akkor kapott nagyobb médiafigyelmet,
amikor február elején bejelentette: otthagyja a vállalatot. A fejlemény önmagában is hírértékű lett volna, de még inkább azzá vált attól, hogy azt a Twitteren egy haikuban közölte."
Az ominózus haiku megtekinthető itt.
Forrás: Index
Szűrsz? Dobj el minden
csomagot. Nem lesz néked
egy sem becsesebb.
Ha VLAN filtert használsz hálókártyáidon és nem jön be rajtuk semmi, ne légy pesszimista, ne a saját szoftveredre gyanakodj először. Inkább ellenőrizd a VLAN beállításokat. Külön elővigyázatosságot igényel, hogy az eredeti teljes forgalom és a VLAN-ra szűrt forgalom két különböző logikai hálókártyaként látszik a legtöbb oprendszer alatt (linux/windows).
Foglalj egy széles
sávot magadnak, majd ne
küldj rajta semmit.
Soha ne ess abba a hibába, hogy a lefoglalt sávszélsességből bármilyen következtetést vonj le a valódi átmenő forgalomra nézvést.
Szoros a verseny,
nagy a tét. Nem ok rá, hogy
megelőzd magad.
Valószínüleg pályafutásom legperverzebb hibajelenségét sikerült izolálni a múlt héten. Az történt ugyanis, hogy egy laborban pöpecül zakatoló linux kernel modul azonnal feldobta a talpát, mikor a számára oly kellemes és megszokott környezetből kihoztuk egy irodába, ahol egy demo erejéig szerettük volna üzemeltetni. Ha visszavittük azonnal meggyógyult, ha kihoztuk megint beteget jelentett és azonnal lefagyott tőle az egész gép.
Csábitó az út,
de bármilyen vonzó, a
semmibe vezet.
Egy fix IP címeket használó hálózaton belül átmozgattunk egy gépet egy másik hálózati részre. A gép többféle hálózati szolgáltatást is használt (SQL szervereket, egyéb sharelt drive-okat és egyebeket), de azt reméltük, hogy újrakonfigurálás nélkül működni fog. Gondolom nem lep meg senkit, hogy nem tette. A szoftvereink küldték kifele a hálózatra a csomagokat, de a gép hálókártyáin már kimenő forgalmat sem sikerült észlelni. Mint utóbb kiderült azért nem, mert az IP címmezők kiosztásánál a felületes szemlélő szerint egy tartományba tartozó 172.31.22.63 és 172.31.22.64 –es cím két különböző tartományba (172.31.22.0/26 és (172.31.22.64/26)) és két különböző gateway mögé került. Emiatt aztán a régi routing tábla teljes mértékben érvényét vesztette. Szóval, ha azt tapasztalod, hogy szoftvered rendületlenül küldi a csomagokat, de a hálókártyákon semmi kimenet sincs, irány a routingtábla editálása (windowson
parancs, linuxon
parancs). És ne definiálj soha olyan címtartományokat, amiket egy felületes szemlélő egy folytonos tartománynak gondolhat, holott nem azok.
Nem baj ha portod
rossz, mig kábeleden
nem jön be semmi.
Minden vasról akkor derül ki, hogy nem működik, ha használni próbálod. Szemre, tapintásra persze ugyanolyan mintha jó lenne.
Ármány. Kártyádról
több csomag özönöl, mint
mit beletöltél.
Kis csomagelemző szoftverünk egy hálókártya driverről szedte le a csomagokat és dolgozta fel őket. Csak hát valamilyen rejtélyes okból kifolyólag a kimeneten sokkal több csomag volt mint amit a kártyára beérkezett. Aztán kiderült, hogy ugyanaz a csomag van jelen a kimeneten sokezer példányban, mert elvettük ugyan a hálókártyától a csomagokat, de nem jeleztük a drivernek, hogy elvettük és feldolgoztuk őket. Így aztán nagylelkűen újra és újra felajánlotta nekünk őket.
Mi megvan, mit semér. Mi nincs, arra szegezda tekinteted.
Ahhoz hogy, e néhány sor mély mondanivalóját teljes mértékben felfejtsük feltétlenül szükséges megismerni az isteni szikra kipattanásának körülményeit. Naplófeljegyzésekből és egyéb önéletrajzi irásokból tudjuk, hogy a költő, aki amúgy is nagyon nehezen viselte a munkahelyén töltött péntek estéket, a vers születésének előestéjén különös természeti jelenségre lett figyelmes. Felületes szemlélőnek talán fel sem tűnt volna, hogy a teljesen működőképsenek tűnő szoftver egy ideje semmi kimenetet nem generál. Ez a jelenség azonban messze túlmutatott önmagán és a világ fájdalmára érzékeny megfigyelőt északi sarkcsillagként vezette a metafizika legsötétebb bugyraiba.
A balsors lavináját az inditotta el, hogy homokszem került a gépezetbe és leállt a szoftver inputjaként szolgáló 4 filestream közül az egyik. Szoftverünk pedig epekedéstűl és sóvárgástúl elvakultan az üres streamre függesztette mélabús tekintetét, mit sem törődve a kihivóan domborodó, gyönyörűséggel kecsegtető többi filera. Ezt próbálta hát a szerző klasszikus formába önteni, a szoftver megszemélyesitésével.
Következtetés:
Ha több erőforrást kezelsz egyszerre (socket, input file, megosztott memória vagy bármi más), ne tegyél semmiképpen blokkoló függvényhívást olyan helyre, ahol az esetleges várakozás az egyéb szálak és erőforrások elérését megakadályozza. Tehát
Applikációd
hibára lel. Nem sejted
mit rejt csomagod.
Hosszú ideje készítünk már TCP/IP/UDP és más protokol stackeken futó hálózati klienseket és elemzőket. Az elején végigböngésztük a megfelelő szabványt, annak alapján megírtuk a protokol feldolgozót, aztán hátradőlve vártuk, hogy minden a legnagyobb rendben menjen. És persze nem ment. Soha nem ment. Kivéve persze, ha mi írtuk mind a két végpontot, de hát ilyen véletlen szerencse ritkán adódik a fejlesztő életében. Mert ha a szabványtól el lehet térni, akkor a másik végpont el is fog és akkor gáz van. Feltéve, ha nem úgy írja az ember a klienst, hogy a szabványtól való esetleges eltérés az alapeset. Persze ez sem egy olcsó módszer, de sokszor még mindig olcsóbb, mint utólag egy külső megrendelőnél javítgatni.
Hogy memóriád
véges, ne bánd. Csillan a
részben az egész.
A Moore szabály szerint a processzorok/számítógépek kapacitása másfél évente megkétszereződik. Murphy törvényei szerint viszont a feldolgozandó adat mennyisége ezt mindig egy kicsivel meghaladó mértékben növekszik. Szóval vagy állandó versenyfutásban élsz az egyre növekvő igényekkel vagy pedig nincs más mód mint kiválogatni a feldolgozandó adatmennyiségből valamilyen reprezentatív/véletlenszerű mintát és beérni azoknak a kezelésével.
Kincs ami nincs a
longint, ha pointered
semmibe mutat.
Egy nagy C++ modulban a memóriahatékonyság miatt pointereket is szép számmal tartalmazó kisebb objektumot küldözgettünk át egy csomó feldolgozó osztályon. Közben persze elkövettük az ilyenkor lehetséges összes hibát:
és még számtalan egyebet is, mert ugye végtelen a pointerekkel összefüggő hibák tárháza. Mikor már elviselhetetlenné nőttek a karbantartási költségek egy nagyobb lélegzetvételű újraírás következett. Hosszabb tanakodás után persze egy referenciaszámláláson alapuló smart-pointer rendszer lett a befutó és azóta is szolgál mindenki megelégedésére. Messze behozta már a ráfordított költségeket.
Bár erős a vágy,
nyílt socketet megnyitni
nem tudsz soha már.
Tesztelés közben kérdésként hirtelen felmerült, vajh miért van az, hogy csak egy kis kódrészletet futtatva remekül sikerül egy socketen kommunikálni, míg ha az egész modult futtatjuk már a socket sem nyílik meg. Aztán persze az idő telik, a tantusz koppan. A socketet valaki egy másik kódrészletben megnyitotta már, dolgavégeztével pedig a lezárással nem fáradozott.
Áldott legyen a
szoftver, csodás hibáink
ébenfa tokja.
Az itt megjelenő haikuk egy valódi szoftverfejlesztő projekt melléktermékei. Kísérteties hasonlóságuk a valósággal egyáltalán nem véletlenszerű, mindegyik megtörtént eseményen alapul. Olyan hibák lenyomatai amiket mi elkövettünk és örülnénk ha te már nem követnéd el őket újra. Az az egyszerű igény szülte őket, hogy próbáljuk meg röviden és tömören megfogalmazni egy-egy hiba vagy egyéb tényállás lényegét, minimálisra csökkentve a kommunikációs üresjáratokat. Mi lenne erre alkalmasabb mint a haiku mindössze 3 sorban, 17 szótagban (5/7/5). Mostantól tehát közzé teszem az eddig született haikukat és próbálom folyamatosan 1-2 hetente frissíteni őket újabbakal.
Amennyiben valaki tud hasonló szoftverfejlesztéssel, távközléssel, hardverrel foglalkozó irodalomról vagy honlapról, kérem jelezzen.