Noha nem fedte fel a problémát, a Forbes.com-nak bemutatta azt. A Forbes megerősítette, hogy a hiba érinti az iPhone-ok legújabb generációját, de a felfedező szerint érintettek más eszközök is, például az iPod-ok és az Apple számítógépek is.
Zambrini állítása szerint a hibát júliusban fedezte fel, majd levelet írt Steve Jobs-nak, amelyben leírta a felfedezését.
A Forbes szerint a szakértő a bugot az "Apple video formátumának audio részében" találta. Egy olyan shared lib-ben, amelyet felhasználnak az Apple operációs rendszerekben és egyes Linux disztribúciókban is. A TippingPoint szakértője szerint a problémának érintenie kell a kernelt is, hiszen ellenkező esetben csak a böngészőnek kellene összeomolnia a kihasználáskor és nem az OS-nek rebootolnia.
A részletek itt.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
"A TippingPoint szakértője szerint a problémának érintenie kell a kernelt is, hiszen ellenkező esetben csak a böngészőnek kellene összeomolnia a kihasználáskor és nem az OS-nek rebootolnia"
Láttam én már OS-t összeomlani mplayer alatt is :)
Amúgy csak költőien kérdem, hogy mi van akkor, ha az adott bug csak az erőforrásokat zabálja agyon ( mem+swap ), és az csapja szét a rendszert??
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
- A hozzászóláshoz be kell jelentkezni
"Láttam én már OS-t összeomlani mplayer alatt is :)"
Árpi már múltkor kifejtette, hogy azok tipikusan nvidia/fglrx driver bugok voltak.
"Amúgy csak költőien kérdem, hogy mi van akkor, ha az adott bug csak az erőforrásokat zabálja agyon ( mem+swap ), és az csapja szét a rendszert??"
Rendszerben nincs megoldva az erőforrások elfogyásának lekezelése. Hülyébb megoldásoknál jön ilyen OOM killer és kinyírja egy bugos progi miatt a többit ahelyett, hogy inkább hibát dobna az alkalmazásnak.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Rendszerben nincs megoldva az erőforrások elfogyásának lekezelése. Hülyébb megoldásoknál jön ilyen OOM killer és kinyírja egy bugos progi miatt a többit ahelyett, hogy inkább hibát dobna az alkalmazásnak.
oooo, melyik alkalmazasnak? Ha egyszerre tiz alkalmazas ker memoriat, de nincs, akkor te mit csinalnal? A kernel honnan tudja, hogy melyik progi a bugos?
- A hozzászóláshoz be kell jelentkezni
Sehonnan, de inkabb a 10 memkero alkalmazasnak dobna hibat, mint lelojon fontosabb progikat az oom-killer.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Honnan tudod, hogy nem a memkero alkalmazas a "fontos"?
Egyebkent meg a "dobna hibat" kb. == "lelovi a programot", a legtobb program meghal ha nem kap memoriat, sok esetben nem lehet ezt lekezelni. Raadasul kezzel beallithatod, ha egy processzt nem engedsz leloni.
Ok igy definialjak, hogy mi a "fontos":
So the ideal candidate for liquidation is a recently started, non privileged process which together with it's children uses lots of memory, has been nice'd, and does no raw I/O.
(google OOM killer elso talalat)
Te hogyan szeretned definialni? (Egyebkent a legjobb az egeszben, hogy definialhatod maskent, csak egy kernelt kell fotditanod hozza....)
- A hozzászóláshoz be kell jelentkezni
És ha hibát dob? Hogyan lehet lekezelni, ha mondjuk egy malloc NULL-al jön vissza? Értelmesen leginkább sehogy, az esetek 99.99%-ában ilyenkor ki kell lépni, azaz ugyanott vagyunk
- A hozzászóláshoz be kell jelentkezni
Én akkor is úgy vélem, hogy inkább z az alkalmazás dögöljön ki, amelyik nem kap memóriát, minthogy valami mást lőjön le a kernel.
Képzeld el azt a helyzetet, hogy van egy program, amelyik nagyon fontos, és beéri az előre lefoglalt memóriájával. Elindítasz egy másik programot, amelyik zabálja a memóriát. Elfogy a memória, mit csinál a kernel? Kilövi a nagyon fontos kevés memóriát zabáló programot, és hagyja futni tovább a memóriazabálót.
Úgy lehet ezt elképzelni, hogy van 2 kocsid. Az egyik kevés benzint eszik, a másik többet. Mindkét kocsiban marad még egy kevés benzin, és annyi tartalék benzined van, hogy az egyiket megtankold. Melyiket tankolnád meg? A kernel azt, amelyikből később fogy ki a benzin.
- A hozzászóláshoz be kell jelentkezni
1. 5 sort kell atirnod a kerneledben, hogy igy viselkedjen, ha szamodra ez tenyleg kritikus.
2. Meg ennyit sem kell tenned, hogy megtiltsd egy adott alkalmazas kiloveset.
3) Képzeld el azt a helyzetet, hogy van egy program, amelyik nagyon fontos, és beéri az előre lefoglalt memóriájával.
Ezek szerint szamodra az a program a fontos, amelyik nem ker memoriat. Nyilvan mindenkinek mas a fontos, de azert ez egy eleg furcsa definicio, nem gondolod?
- A hozzászóláshoz be kell jelentkezni
1: szerencsére nem szoktam így járni, amíg nem érint addig így marad. :)
2: ez ok, jó, hogy lehet ilyet, de ez egy "tervezési hiba" megkerülése. (Persze mindenkinek mások az igényei.)
3: sajnos példa nélkül nem tudok válaszolni. Van egy szervered, daemonokkal. Van még erőforrásod, elindítasz még valamit, de az bugos, zabálja az erőforrásokat. Mind fontos, de én úgy vélem, hogy inkább a bugos dögöljön ki, mint az összes többi nem bugos. És ez úgy valósítható meg, ha a kernel azt öli meg, amelyik már nem kap memóriát. Persze ez nem életbiztosítás a többi daemonnak, de szerintem hamarabb fog így kidögleni a bugos daemon, mint a jelenleg működő módszer szerint.
- A hozzászóláshoz be kell jelentkezni
hogy inkább a bugos dögöljön ki ... És ez úgy valósítható meg, ha a kernel azt öli meg, amelyik már nem kap memóriát
Ez tevedes. (Legalabbis, amig ala nem tamasztod meresekkel.) Semmi sem biztositja, hogy a "rendes-fontos" program kevesebbszer ker memoriat mint a bugos. Kb. biztos vagyok benne, hogy egy apache pl. siman ker memoriat minden egyes request eseten. NFS szerver szinten.
Arrol nem is beszelve, hogy itt foleg nem arrol van szo, hogy a malloc() nem fut le, hanem pl. ha fork() eseten nem tortenik egybol masolas, es a gyerek modosit egy lapot, akkor ugye meg csak memoriat sem kert es megis kellene neki adni.... nincs kinek hibat visszadni lenyegeben, mert nem volt system call sem. Namost ilyenkor ketto lehetoseg kb. 1) kiloni az adott programot, ez kb. akkora esellyel "fontos" mint "bugos" 2) megprobalni valami heurisztikat definialni, hogy melyik program a fontos. Utobbit csinaljak. SZVSZ jogosan.
Egyebkent is az egesz OOM killert ki tudod kapcsolni, on the fly, illetve az overcommitment-et, es akkor nincs OOM killerre szukseg.
Nem igazan tudom, hogy mi bajotok van ezzel a design-nal, foleg mivel allitasod szerint sohasem talalkoztal a problemaval.....
- A hozzászóláshoz be kell jelentkezni
Na ezért nem ájfónom lett... meg azért mert drága...
Igaz h a HTC S710esemen a Windows Mobile 6 naponta összeomlik (opcionálisan el is kúr valamit) de legalább otthon lehet javítani...
- A hozzászóláshoz be kell jelentkezni
Szabad azt megkérdeznem, hogy a WM6-hoz mennyi biztonsági javítás jött ki az elmúlt ühm. 2 évben?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Hihi, a Symbiannak meg nem volt szüksége biztonsági frissítésre az elmúlt két évben, legalábbis nem verték nagy dobra, ami azért a legnépszerűbb OS-nél jelenthet valamit. (vö. Windows)
És normálisan kezeli az elfogyó erőforrásokat :) (Persze ha a fejlesztő figyel a jelzésekre, nyilván.)
- A hozzászóláshoz be kell jelentkezni
Nos, Symbiannal testkozeli elmenyeim csak SE es egy keves Nokia kapcsan volt. Nem lattam meg embereket annyit szentsegelni mint ezek miatt. Pazarlo es illogikus eroforras kezeles, szimplan hibas funkcionalitas, nehezkes kezelhetoseg, fagyasok, kihullott hajak es lekapart tapetak jellemeztek a hasznalatat.
iPhone-ban is vannak baromsagok boven, de legalabb nem csinal olyat, hogy WiFi jelenleteben is a 3G-t erolteti hasznalatra, mint ahogy azt a legujabb Nokia kommunikator teszi. Ami akarhonnan nezzuk baromsag.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Symbiannal testkozeli elmenyeim csak SE es egy keves Nokia kapcsan volt.
A Sony-Ericsson telefonokon futó UIQ felület hírhedt a rossz erőforráskezelésről. Igazából az instabil szoftver mellé a gyártó nem is rakott alá elég vasat... Balszerencse, hogy ezt kellett megtapasztalnod.
Viszont valamit elnézhettél azon a kommunikátoron. Ha a böngészőre gondolsz, ott bár kirakja a 3G jelet, nem használja azt, ha a WLANt választottad ki. Ez a UI bug pl. E51-esen és más FP1-es telefonokon is így van.
- A hozzászóláshoz be kell jelentkezni
Nem bongeszoben bukott le, hanem a belso halo elerese okozott fejtorest a szerencsetlennek. Mert hiaba volt WiFi-re kotve, attol meg nem ott probalkozott.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Nokiánál nyilván megvárják az első nagyobb vírusjárványt, aztán majd kijavítják a hónapok óta ismert biztonsági hibákat. Én legalábbis biztonsági hibának nevezem, ha egy jogosultságok nélküli program meg tudja oldani, hogy írni és olvasni lehessen a rendszerfájlokat.
- A hozzászóláshoz be kell jelentkezni
Én inkább áldásnak hívom a HelloCarbide-ot, de ez egy másik történet. (És semmi köze a kalózprogramokhoz.)
- A hozzászóláshoz be kell jelentkezni
Ha szerinted jobb az, ha valami naponta összeomlik (és el is kúr valamit) mint az amit egy hiba miatt fixen lehet dönteni, de ezt nem teszi meg magától akkor egészségedre.
- A hozzászóláshoz be kell jelentkezni
Szerintem meg egyik sem jobb.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Akkor neked semmi nem jó :)
- A hozzászóláshoz be kell jelentkezni
okos!
- A hozzászóláshoz be kell jelentkezni