30+ éves bugot fedett fel Otto Moerbeek malloc-ja

 ( trey | 2008. július 8., kedd - 18:30 )

Otto Moerbeek egy ideje új malloc implementáción dolgozik az OpenBSD-hez. Az általa fejlesztett megoldást már többen is tesztelték, és egy ideje már elérhető a snapshot-okban is. Nemrég Nikolay Sturm jelezte Otto-nak, hogy sparc64 gépeken nagyobb C++ projektek fordítása néha elszáll Internal Compiler Error hibával. Megkezdődött a nyomozás, amelynek a végén egy ősi (az Undeadly.org szerint kb. 33 éves) bug került levadászásra a yacc(1)-ban. A sztori itt olvasható.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"A nyílt forrású szoftverek azért jók, mert azokban nem maradnak sokáig rejtve a bugok, hiszen bárki megnézheti a forráskódokat..."

;D

troll! inkabb orulnel, hogy ennek a bugnak is szep bsd liszensze van!

---
Apple iMac 20"
áéíóöőúüű

Szinte éreztem, hogy az első válasz valami hasonló lesz:)


::sumo.conf::

Zart forras eseten varhattak volna a forras tulajanak a debugjara/patchere. 30+ ev utan igen naiv dolog lett volna supportot remelni ;D
--
ahan nem

Úgy látszik, hogy növekszik a forráskódot átnézők tábora ;)

es kulso cegek auditaljak is a kodot

#toy like ppl make me boy like

NÁZA

Szep. A kerdes az, hogy az adott bug meg lett volna e talalva valaha is, ha ez nem nyilt forraskodu. A "soha"-hoz kepest a 33 ev eleg pici ido.

a 'soha'-t hogyan számoltad ki?

megkerte chuck norrist

#toy like ppl make me boy like

33 < ∞

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

tudom, crack sem létezik semmihez

Kis sunyi, azt hitte, megússza ott a sötétben... :)

Jó munkához idő kell. .-)

--
"Kernel fordítás, fúj... Pótcselekvés."

A hosszú munkához idő kell. ;-)

--
Who is Peter Whooshing?

A lassu munkahoz ido kell!

A'rpi

A rosszhoz még több...

A színlelthez meg a legtöbb...

Érdekesek ezek az ""oldboy"" bugok. Nincs tökéletes munka. De legalább kiderülnek. Na a lényeg az, hogy miféle nyelven lehet ez, mert 33 év alatt a C is annyit változott (volt egyéltalán 33 éve C)?

"The initial development of C occurred at AT&T Bell Labs between 1969 and 1973; according to Ritchie, the most creative period occurred in 1972" forras: wikipedia
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Köszi a konkrétumot. ;)

minden szoftverben van olyan hiba, amit a szoftver teljes élettartama alatt sem találnak meg, szóval nincs itt semmi látnivaló

en is talaltam egy ~15 eveset multkor, nincs ebben semmi erdekes, egyszeruen nem volt szem elott. :)

--
“A well placed underscore makes the difference between a s_exchange and a sex_change”
— 8048 Users Manual, Intel 1977.

ráadásul manyeyeball úr még csak 32

Szerintem valamit félreérthettél az iskolában amikor a manyeyeball urat magyarázták..

--
trey @ gépház

can i has a lessoen

_miután_ kiderült hogy hibát okoz, megkeresték a problémás forráskód-részletet (ugye milyen furcsa hogy ezt meg tudták tenni?), megtalálták, javították.

elég perverz elképzeléseid vannak ha szerinted minden foss hívő folyamatosan forráskódokat olvas lefekvés előtt...

illetve hát pont nem nekem

szemelvenyek a hup poen rovatabol:

http://hup.hu/cikkek/20080705/jatszhato_demo_a_blender_institute_elso_nyilt_jatekabol#comment-596043

"Mond, Te fogyatékkal élő vagy, vagy csak szövegértési problémáid vannak. Sehol nem állítottam azt, hogy a Linux KERNELT auditálják, hanem azt mondtam, hogy a mission critical területeken igenis szokás auditáltatni a más cég/közösség/atyaúristen által készített kódot, mégha ez számodra az újdonság erejével hat is. Ha az éppen FOSS kód, akkor is, hiszen abban is van hiba."

http://hup.hu/node/57660#comment-594339

"Nem, mivel egy széles látókörű személy tudja, hogy minden zárt forrású termék untrusted, mivel nem lehet tudni mit csinál valójában a kód, nyílt forráskód esetén azonban bárki átnézheti a kódot, ezért nagyobb bizalmat lehet adni egy nyílt forrású rendszernek, mint egy zárt forráskódúnak.

Kemény, technikai érvek ezek."

#toy like ppl make me boy like

nem értem miért kell olyan elánnal vitatkozni mindennel amivel nem értesz egyet hogy az még a marsról is látsszon. lehet readonly módban is jókat mosolyogni mások elvakultságán...

A probléma gyökere valójában pont ugyanott van nálad, ahol willy esetében is, miszerint a "milyen furcsa hogy ezt meg tudták tenni" kérdés/kijelentéseddel olyan érzést akarsz kelteni, mintha a bugokat forráskód nélkül fel sem lehetne deríteni...

Igazából ez a félrevezetés az, amely miatt szót emelnek a nem-csak-csendben-jókat-mosolygók. ;)

> mintha a bugokat forráskód nélkül fel sem lehetne deríteni...

Amennyiben a bug javításának módja a forráskód módosítása, akkor valóban. Az egyéb eseteket hagyjuk meg a mazopistáknak.

Én a bug felderítéséről írok, te pedig a bug javítására "reagálsz". Szándékos csúsztatás?

Nézd már meg jobban, hogy ki írta.


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

:DDDD

#toy like ppl make me boy like

itiz dö bigining avö bjutifúl frencsip

te mit ertesz bugok felderitese alatt? azt hogy konstatalod, hogy segfaultol ez a sz@r, nos igen ezt zart forrasu programmal ugyanolyan jol meg lehet csinalni. Ha ennel tobb kell, akkor azert jobb ha megvan a forras - pl. a cikkben az uriember sem jutott volna ilyen egyszeruen a vegso konkluziora ha a MS Office lett volna a hibazo program.

- Use the Source Luke ! -

gondolod ha tegyukfel seggfaultol az office es ezt reportolod a microsoftnak akkor ok nem nezik meg a forraskodot?

vagy megis hogy tibike?

azert mert bugrisjani nem lathatja a kodot meg ugyan az a javitas menete legyen az openszorsz vagy closed szorsz

right?

#toy like ppl make me boy like

es Otto hogy gyozodik meg arrol, hogy nem a malloc kodjaban van a hiba? Megnezi az office-t gdb-ben (de mondjuk nem akar asm kodot bogaraszni)? Vagy majd a microsoft kuld neki levelet, hogy megneztuk es nalunk volt a hiba? Ez igy szerinted tenyleg egyszerubb/jobb mint a cikk eseteben ahol Otto-nak megvolt a forras keznel?

- Use the Source Luke ! -

meg mindig nem arrol beszelunk h otto mit csinalt vagy csinal
hanem arrol h semmi koze az opensourcenak ahhoz h hogyan javitanak egy bugot

de ha mar muszaj ezzel a jasonlattal elni akkor otto ir egy olyan progit ami closed source libet hasznal es elszall akkor szerinted nem lehet kidebugolni h hol szall el? ott all ertetlenul es berakja a tokyo hotel cdt es elkezd sirni?

te komolyan programoztal valaha barmit is?

#toy like ppl make me boy like

persze nem a bug kijavitasarol beszelunk, hanem a "feltarasarol", barmit is jelentsen az :D.
amugy nyilvan konnyebb kidebugolni ha meg van a forras. jelen esetben is Otto beinditotta a gdb-t es rogton latta, hogy hol a hiba, biztosan nem az o kodjaban - amugy nehezebb bebizonyitani, hogy az o kodja hibatlan egy bug feltunese eseten.

- Use the Source Luke ! -

Ki lehet bármit debugolni, nem (csak) erről volt szó. Azért én valahogy könnyebben debugolok ha látom a forráskódot is...

Akár hiszed, akár nem, van az úgy hogy egy bug nálad mindig előjön, de a vendor nem akarja javítani, mert a 3 millió userből 2 darab panaszkodik miatta. Ne mondd hogy ilyenkor nem kényelmesebb saját magadnak megjavítani, mint a teljes solution-t kicseréni másik vendor megfelelő solution-jére.

Ja, persze lehet hogy ahol nagyon kritikus ott megveszik a supportot és megkapják az egyedi javítást. Vagy nem. Vagy el sem kezdik használni éles környezetben, supporttal, mert az adott körülmények között nem működik tökéletesen a sw.

vizualizalom ahogy a debian mentener srac az openssl bug javitasa utan belajavit az oracle kodjaba aztan bekommitolja

miaz h a vendor nem torodik valamivel?

lol?

kicsengetek mondjuk 10M-t licenszre aztan odamesz h dehat kressel, okmeg visszairjak h leszarjuk

ahahaa mosmar csak azt kene idepottyintened melyik magyar Bt nel vagy debian admin

#toy like ppl make me boy like

Idézet:
vizualizalom ahogy a debian mentener srac az openssl bug javitasa utan belajavit az oracle kodjaba aztan bekommitolja

Tudod, az a mondás járja hogy csak az nem hibázik, aki nem dolgozik. Nem akarom védeni a debianos maintainert, ellámázta és még a kommunikáció is rossz volt.

Idézet:
miaz h a vendor nem torodik valamivel?

lol?

kicsengetek mondjuk 10M-t licenszre aztan odamesz h dehat kressel, okmeg visszairjak h leszarjuk

Vagy csak annyit hogy köszönjük, a következő release-ben javítva lesz, hacsak más, magasabb prioritású feladat nincs. Esetleg azt, hogy ismert probléma amennyiben a másik rendszerkomponens x.y verziójával nem működik jól ha a mars együttáll a jupiterrel, frissíts x.y+2-re. Nyilván sarkítottam - de ha megindokolod. hogy szerinted miért rosszabb, ha egy kereskedelmi termék mellesleg nyílt forrású is, azt szívesen meghallgatom.

Idézet:
ahahaa mosmar csak azt kene idepottyintened melyik magyar Bt nel vagy debian admin

Pardon? Hogy jön ez ide?

ugyhogy nyilvanvaloan fogalmad sincsen a vendor supportrol

#toy like ppl make me boy like

Idézet:
Vagy el sem kezdik használni éles környezetben, supporttal, mert az adott körülmények között nem működik tökéletesen a sw.

erre gondoltam. de valóban, rajtad kívül mindenki csak feltételez itt, és csak te tudod a true-t :)

nem igaz mert vannak meg paran ;)

#toy like ppl make me boy like

double decker

#toy like ppl make me boy like

guinness rekord?:)
-----
kit erdekel milyen kernel?

FIXME, de akkor ez a bug benne van a kereskedelmi UNIX-okban is, nem? Sot, meg akar OSX-ben is, XCode-ban csak van yacc. Szoval ok csak ugy atveszik a bugos FOSS code-ot anelkul hogy atneznek, vagy mi? :) (Csak hogy lemenjek a manyeyeballozok szintjere.)

NAME
     yacc -- parser generator

DESCRIPTION
     On Darwin, yacc is a wrapper for bison(1), equivalent to bison -y.

---
pontscho / fresh!mindworkz

Jah, kesobb eszembe jutott, kosz. Emlekeztem (utolag) hogy az XCode eleg regi bison-t szallit, ebbol volt is compiler error OSX-en.

Egyebkent a yacc-ot meg fejleszti valaki? Nem hinnem, mar a bison-t sem igazan fejlesztik, nehany evig fent voltam a bison levelezesi listan, kb. 1 email per honap volt a forgalom....

igazabol nincs hova fejleszteni, a formalis nyelvek elmeleteben nem tortent sok ide kapcsolodo valtozas, LL(n) meg LR(n) nyelvek mar ugyanazok par eve [es ugye ezekhez tudsz generalni parsert..]

Persze, ez vilagos, ill. LALR(1) ha jol tevedek. Vagy lehet LL(1)-hez is pl? Asszem ekvivalens, de a szabalyokat LALR(1)-ben kell megadni.

Ettol fuggetlenul meg lenne mit fejleszteni, pl. C++ parser generalas, tobb parser egy programban, ezek nem tul gordulekenyek.

*Szerintem* a kerjujnikszok nem a BYacc implementációt használják, hanem a saját AT&T-féléjüket. De majd valaki kijavít. (Attól még osikszben benne lehet.)

Jól tudom, hogy a legtöbb compiler és interpreter kiértékelője a lexx/yacc párost használja? Mert akkor ez rengeteg programot érint!

igazabol csak egy kis szeletet, megpedig ahol ures nyelvtani szabaly is van a nyelvben (RTFA)

johat epp gccnel kijott ;)

Huszonöt évvel ezelőtt a Számalk- ban Pető Ádám tanárúr magyarázta, hogy miért nem jó a malloc, Ő írt egy omalloc fvt helyette, azt használta. Akkor ámulva- bámulva halgattuk előadásait, de nem mindig voltunk szinkronban. Ő akkor az "átkosban" megelőzte korát, jó könyveket írt, bugjavításairól nem tudok, akkor az itt keleten nem volt divat.
--
üdv: virtualm