Názory k článku
Firefox prý obsahuje nejméně 726 problémů
-
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)IMHO ziadny automaticky nastroj nedokaze rozlisit "skutocny problem" od "potencialneho problemu". Mam s par testovatkami skusenosti (napr. valgrind, java findbugs, nejaky C-ckove udelatko...)
Napr. pri pythone valgrind sype "invalid read" (pokial sa nezadefinuje urcity preprocessor symbol) takmer v kuse, pretoze python ma vlastny alokator pamate, alokuje pamat na "areny", co su 4-kB kusy pamate zarovnane na hranicu 4kB. Ak by nejaka architektura mala stranky mensie nez 4kB, tak by namiesto testu, ci je dana alokovana pamat uz "claimnuta ako arena", by sposobil segfault (nepamatam si to uz uplne presne, ale cca pred rokom som riesil ten problem, nakoniec sa ukazali memory leaky v nasej app).
Podobne, jedno C-ckove udelatko sa "chytalo" na strcpy, pricom strncpy ohodnotilo ako OK.
Lenze:
-pred strcpy sa da samozrejme porovnat a otestovat maximum
-pri strncpy sa to da zase naopak pos..t (ak sa clovek dost snazi ;-))
Napr. dost pochybujem, ze by nejake udelatko dokazalo vo FF detekovat, ze dakde mu chyba wait(), co je uz nakoniec mozno opravene, ale pamatam si, ze obcas nejake child procesy ostavali visiet. -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)K pythonu: bola tam funkcia int is_arena(void * addr) alebo podobneho nazvu/signatury. Otestovala ci na adrese addr&0xfffff000 je "signatura" pythonovskeho alokatora. Tj. ak dostala nejaky kus pamate alokovany obycajnym mallocom, sahala casto do neinicializovanej (pripadne nealokovanej) pamate. Ze to nesegfaultlo rovno je dane tym, ze (snad vsetky zname) architektury pouzivaju aspon 4kB stranky, inak by pagefault handler zistil, ze sa deje nejaky bordel. V podobnom zmysle je mozne najst v zdrojakoch pythonu komentar. Pre tu srandu, pregrepujte si zdrojaky pythonu na vyraz 'valgrind' :-)
-
Robert O'Callahan, jeden z hlavních vývojářů Gecka, má k balíku 726 možných problémů komentář Static Analysis And Scary Headlines, kde v podstatě potvrzuje můj předpoklad: zatím z těch sedmi stovek jsou potvrzené 3–4 chyby, většina ostatních byla označena jako falešné poplachy. V komentáři je uveden i jeden příklad konkrétního planého poplachu. -
Zatial mam skusenosti len so splint-om a po patricnej uprave command line co vsetko mi hlasit ma a nema a pravidelnom pouzivani od zaciatku vyvoja jednej kniznice to mam v takom stave ze nehlasi ani jeden warning, a pomohol mi odhalit 2 skutocne chyby. (v pomere na rozsah kodu a pocet chyb ktore som musel odhalit rucne pretoze staticka analyza ich odhalit nemohla.... nic moc)
Hlavne to vyladenie hlaseni bolo bolestive, kedze niektore hlasenia splintu su vyslovene carovne, napr. upozornenie ze konstanta 0x45 po konverzii do BYTE by mohla stratit informaciu a pod. nezmysly.
Pustit to so standartnym nastavenim na nejaky zdrojak ktory s tym nebol od zaciatku kontrolovany, tak clovek dostane kludne cez 1000 varovani,a ak mu pomozu odhalit aspon 5 chyb, tak moze byt stastny ze sa to vyplatilo.
Klocwork som nevidel, takze tazko posudit nakolko je tych 726 hlaseni relevatnych.. -
Honza (neregistrovaný)Používám FF 1.5.0.6 na WinXP a jsem přesvědčený že FF má problémy při práci s pamětí. Při otevření více tabů s různými stránkami se alokovaná paměť pohybuje klidně okolo 80 - 100 MB. Po zavírání jednotlivých tabů se alokovaný objem paměti nesnižuje, jak by se dalo čeka, ale zůstává víceméně stejný. Takže když skončím na závěr s jediným tabem, ve kterém je primitivní, převážně textová, stránka (např. starý www.linux.cz) a FF má alokováno celkem 80-100 MB paměti, říkám si že je tam něco shnilého.
Má někdo z vás podobnou zkušenost? -
Honza (neregistrovaný)Ze strany Klockworku jde samozřejmě o dobrý pokus o zviditelnění jejich produktu. A to bez ohledu na to, jestli těch 726 problémů je skutečných, potenciálních a nebo virtuálních. V každém případě se spousta lidí dozví, že existuje společnost Klockwork, která se zabývá statickou analýzou kódu. A o to, myslím, šlo.
