Nejobskurnejší bug

12.9.2009 03:08 | Přečteno: 1736× | programování

Dnes na odlehčenenější tému. Obskurních bugů jsem si užil spousty, ale na tenhle nezapomenu.

Měli jsme editor kódu (widget poděděn od QTextEdit), nazvime ho pracovně ParsingTextEdit. Bylo to pro jazyk, který je kombinací ("kartézský součin") Verilogu, VHDL a MASTu (syntakticky nejblíže Verilogu). Plus všechny super-featury jako syntax-highlight, atd. Potud dobrý.

Editor s okamžitým překladem

Jenže ParsingTextEdit navíc již při editaci parsoval podle gramatiky vložený kód do abstraktního syntaktického stromu (kromě výrazů, to řešil separátní parser/překladač později). Když jste někdy zkoušeli programovat na ZX Spectru/Didaktiku, víte jak kurzor skákal po celých tokenech (for, if, atd.). Podobně se choval ten náš ParsingTextEdit (jenom nebylo třeba mačkat N shiftoidních kláves s pěti rukama). Nevím, kdo vymyslel ten requirement, aby ten editor takhle fungoval, prostě to tak bylo.

Bug report

Bug report zněl: Když napastuju nasledovní kód, zakomentuje se mi celý:

for(i=0; i < limit; i=i+i) {
    analogInit = a+b+c*nejakyVyraz
}

Debugování parseru v ParsingTextEdit nic rozumného nepřineslo, nastoupila hrubá síla. Zkoušeli jsme pastovat všechno co šlo, jak zmysluplné kusy kódu, tak náhodný bordel.

Eventuelně jsme přišli na to, že když proměnná začíná na analog, tak se parser ParsingTextEdit zblázní a zakomentuje celý blok, protože je podle něho syntakticky špatně (v tomhle případě celý for cyklus).

Rozuzlení (nebo rozezlení nebo odezlení)

Proměnná začínající řetezcem analog byla hodně podezřelá proto, že analog je klíčové slovo ve Verilogu. Eureka - při inspekci flexového zdrojáku gramatiky pro ParsingTextEdit chyběl za analog symbol dolaru (konec regexpu). Proto bral analogInit za klíčové slovo. Říká se, že ve velkých firmách není neobvyklý 5 řádků kódu za den na člověka. Ale 12 člověkohodin na jeden znak taky není špatný

       

Komentáře

[deda.jabko]

Ale 12 člověkohodin na jeden znak taky není špatný.

to je naprosto normalni... me prijde, ze pomalu chyby delsi nez jeden znak neopravuju...

treba jsem dva dny hledal jeden priserny race-condition... nez jsem si vsiml, ze misto fork() ma byt vfork().

a nedavno jsem dokonce udelal release, kde se menili jenom dve pismenka, ktery opravoval dve vazne chyby...

[kolcon]

meli jste tam rm misto mv? ;)

[michich]

treba jsem dva dny hledal jeden priserny race-condition... nez jsem si vsiml, ze misto fork() ma byt vfork().

To mě zajímá. Můžeš tento případ trochu rozvést? Nenapadá mě, jak taková záměna může způsobit race. A pokud vfork opravdu pomohl, tak bych očekával, že se na to nesmí spoléhat - vzhledem k tomu, že podle manuálu je přípustné, aby vfork dělal totéž co fork:

The requirements put on vfork() by the standards are weaker than those put on fork(2), so an implementation where the two are synonymous is compliant. In particular, the programmer cannot rely on the parent remaining blocked until the child either terminates or calls execve(2), and cannot rely on any specific behavior with respect to shared memory.

[andree]

yop, jednoznakove chyby su vacsinou dost zabavne...

ja som pred dobou riesil neprijemny freeze-bug kvoli chybajucemu znaku "*" :) doteraz som nepochopil, preco to ako chybu nenahlasil gcc (v c++ kode), bolo to nieco na tento styl:

void fct(Data *) { ... }
Data **x;
fct(x);

o to vacsia sranda bola najst to...

[Jardík]

Máš kompilovat s -Wall -pedantic

[andree]

bol to projekt vyrobeny pomocou qmake, takze -Wall tam je.. a -pedantic pomoze len k tomuto:

/usr/include/qt4/QtCore/qglobal.h:798: error: ISO C++ 1998 does not support ‘long long’
/usr/include/qt4/QtCore/qglobal.h:799: error: ISO C++ 1998 does not support ‘long long’

... dalej som to neskumal...

[Jardík]

No vždyť to je špatně, tak pedantic pomohl. long long je v C99 nebo až v chystaném C++0x, takže ho v C++ použít "nesmíš"

[andree]

tak to aby niekto napisal trolltechu/qt software/nokii... :)

[Jardík]

Tak na 64bit to není problém, tam můžou místo long long použít long (na I*LP64) či pointer (předpokládám, že tím řeší 64bit číselný typ), i když je to prasárna největšího kalibru

[limit_false]

Hm, to by gcc melo zarvat, tedy pokud to neni nejak premakrovano jako napr. #define Data void.

Jaka verze gcc?

[andree]

gcc 4.3.3, ale preslo to aj na starsich...

ano, je to void, ako teraz pozeram... Sice mi pride divne, ze void** sa da implicitne pretypovat na void*, ale tak aspon som zase o nieco mudrejsi A aby som nemlzil, tu je kod:

typedef PaStream void;
PaStream* paStream;
...
Pa_CloseStream(paStream); //chybne: Pa_CloseStream(&paStream);


[Jardík]

Ano, na void* se v C++ dá implicitně přetypovat všechno, takže to pak je problém. Ale tvůj problém bych řešil např. takto:

/* v C stylu */
typedef struct _PaStream PaStream;
/* forward deklarací v C++ */
struct PaStream;

Pak ti to přetypování neprojde.

[andree]

yop, tak by som to ja riesil tiez.. len toto je externa kniznica (konkretne PortAudio v19), takze to je zlozitejsie..:) ale asi im aspon bug vyplnim...

[petr_p]

Eventuálně (eventuělně) má v češtině jiný význam než v angličtině :)

[limit_false]

No s tema slovama a jejich vyznamama je to fakt opruz . Zvlastni je, ze podle wiktionary to snad vsechny jayzky krome anglictiny maji jako v cestine (nemcina, francouzstina, holandstina...). Pritom podle latinskeho eventus bych nejspis rekl, ze ten anglicky vyznam je spravne.

Podobne jako apokalypsa neznamena konec sveta ale, "odhaleni velikeho tajemstvi", byrokracie mel byt puvodne idealni system spravy (jmeno filozofa jsi nevzpomenu). Podobne Finkelstein zprofanoval slovo liberal.

[Michal Kubeček]

Podobně zrádné je třeba slovo actual (viz třeba titulní strana www.bsg.cz nahoře).

Podobne Finkelstein zprofanoval slovo liberal.

A teď pracuje pro stranu, která se už od svého založení označuje za "stranu konzervativně liberálního typu". :-)

[User682]

>Říká se, že ve velkých firmách není neobvyklý 5 řádků kódu za den na člověka. Ale 12 člověkohodin na jeden znak taky není špatný

Klasika. Za posledni tyden mam asi 15 placenych clovekhodin na jednu anotaci na jeden radek. Clovek uz chtel potom v zoufalstvi psat generator kodu (Plan C).

Ale s tim jednim znakem vedete.

Prace tohoto typu jsou na palici. Po 3 dnech je to potom na flasku vodky. Vetsinou se to pak vyresi.

Jinak rekord na jednu chybu mam asi 5 dni v kuse. Zakaznik to chtel a muselo se to vyresit.

[Jardík]

Nepíšete s háčkama/čárkama a já místo "flašku vodky" viděl "flashku vodky" a bylo mi to nějaký divný

[limit_false]

Nastesti obskurni bugy nenastavaji az tak moc casto (ted mam vyjimku, protoze jsem zdedil software, kde prave vsechny race conditiony a podobne zabavne bugy se nikdo neobtezoval/neumel opravit).

Jiz nekolik krat se mi stalo, ze nez hledat bug, bylo to rychlejsi prepsat nanovo (taky jsem jednou hledal bug tyden). To jde kdyz je to kod v radu tisicek, maximalne desetitisicek radku, od cca 50.000 to uz neni celkem sranda, specielne kdyz nevite co se od toho kodu ocekava (jake invarianty, vystupy apod.). Neokomentovany prekladac, kde jsou jenom deklarace C++ sablon s 3 urovnemi vnoreni psane na 5 radku, je prave takova chutovka - lepsi nedotykat se.

[default]

Klasický šibeniční kód. Jednu stranu rozpleteš, druhá tě uškrtí.

[Michal Kubeček]

Jiz nekolik krat se mi stalo, ze nez hledat bug, bylo to rychlejsi prepsat nanovo (taky jsem jednou hledal bug tyden).

Na to jsem přišel poté, co jsem přes hodinu hledal na PMD-85 chybu spočívající v tom, že jsem napsal IMPUT místo INPUT (jindy zase T0 místo TO). Na druhou stranu, kdybych ten řádek prostě smazal a napsal znovu, nikdy bych nezjistil, co tam bylo špatně.

[default]

Mně se zase stalo, že jsem debuggoval SQL dotaz. Prostě to vracelo blbý data. Ale jen někdy.

Zjistil jsem, že jsem zapomněl před sloupek ve výrazu OVER() dopsat alias tabulky. Oracle si bohužel vybral tabulku špatnou.

[limit_false]

Taky mam radsi zjistit, v cem je chyba. Ten tyden-hledan-bug pochazel ze zdedeneho kodu, kteremu mirne prepsani neuskodilo. Na druhou stranu ne vzdy ze cas zjistovat uplne do podrobnosti proc se kde co a jako stalo (navic po tydnu ladeni toho bugu jsem mel celkem dost).

[Michal Kubeček]

Na druhou stranu ne vzdy ze cas zjistovat uplne do podrobnosti proc se kde co a jako stalo (navic po tydnu ladeni toho bugu jsem mel celkem dost).

Ono stačí i výrazně méně než týden, když má člověk každých půl hodiny za zády šéfa (nebo na telefonu zákazníka) s dotazem, kdy už to bude chodit. :-)

[limit_false]

Jo a pak pri oprave toho bugu vnese do kodu dalsi

[User682]

zdravim,

a jeste pridam.

- Hodne skody obcas nadela IDE. Ne -li Ctrl+C a Ctrl+V. - hodne taky skodi prepisy vuci anglictine nebo cestine treba pri pojmenovani promennych, tabulek. Idealne, kdyz je to rozhrani nebo database, kterou nemuzete menit. - To nejhorsi, co jsem zazil, je vlastni kod. Idealne, kdyz se k nemu vratite po par letech. To je potom to prave peklo. Nejlepsi reseni je prepis nebo refaktoring, pokud to vubec jde. Je to nejhorsi kod, co jsem videl, a jmenuje se to linuxsoft.cz .

[limit_false]

Nejhorsi vlastnost spatne napsaneho kodu je, ze se zprasenost nabaluje. Jak je to jiz jednou dostatecne zpraseny, odprasit je to tezke. Hlavne v komercni sfere, kde na to proste nedostanete cas a prasi se to dal.

Druha nejhorsi vec je, kdyz vedeni rozhodne, ze se to nejak naprasi, aby to bylo rychle. Ze se pak stravi 2x vice casu pri debugovani a opravovani, jaksi nikdo nevidi. Jak nekdo rika "rychle, levne, dobre - vyber dve", ja bych to opra(s|v)il na "rychle, levne, dobre - vyber jedno".

Tretni nejhorsi vec je, kdyz na namitku "kdyz se to udela takhle, pak bude velice tezke udelat XY, co vime, ze bude nutne naimplementovat" je odpoved, prekvapive opet: "Tak se to naprasi tak, pak se s tim neco udela."

Paradoxne se to takhle deje i kdyz zadny zakaznik danou funkcionalitu okamzite nepotrebuje.

BTW zrovna odprasuju kod, ktery jsem zdedil s nadhernyma race-conditionama. Skutecne uvazuji nad implementaci distribuovanych snapshotu.

Ad refaktorizace: napada me zrovna: "Without solid suite of tests you are not refactoring, just changing shit around" (pochazi odsud)

[eoj]

pochazi odsud

Odkud?

[limit_false]

Netusim na co se zrovna ptas, ale je to v tom odkazovanem clanku:  http://hamletdarcy.blogspot.com/2009/06/forgotten-refactorings.html

Ja udelal kratkou parafrazi, cela citace zni:

I don't know how much more emphasized step 1 of refactoring could be: don't touch anything that doesn't have coverage. Otherwise, you're not refactoring; you're just changing shit. And not a single IDE enforces or encourages you to have test coverage before mucking about with the refactorings.