Komoly VMware bug miatt leállhatnak a virtuális gépeink

Bug

"All your VM's are belong to us" című blogbejegyzésében figyelmeztet minket Matthew Marlowe arra, hogy a mai naptól kezdve egy bug folytán a VMware ESX 3.5U2-n hostolt virtuális gépek leállítás után nem hajlandóak elindulni. Úgy tűnik, hogy valami bug van a VMware licencekezelő kódjában. A VMware vizsgálja a problémát és javítást ígér. Addig is, amíg a cég elkészül a javítással, ideiglenesen meg lehet kerülni a problémát az NTP szolgáltatás leállításával és a dátum kézzel történő visszaállításával. A futó virtuális gépek addig nem érintettek, amíg futnak, így kerülendő a leállításuk. A hibajegy szerint holnapra várható a javítás. A témában hosszú szál indult a VMware közösségi oldalán. Matthew blogbejegyzése itt olvasható.

( XMI | 2008. 08. 12., k – 22:49 )

ÁÁÁÁ! És én még azt hittem, hogy megúszom a szabadságom alatt a szervermcsesztetést.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

( Nyosigomboc v | 2008. 08. 12., k – 23:31 )

VGA: VMware Genuine Advantage. Koszonjuk, +1 erv a nyilt forras mellett.

----
It doesn't take a rocket scientist to program a computer, it takes a programmer.
honlapkészítés

Ja majd warezportalon meg majd olvasssatok, a #42 -es haxxorunk altal fejlesztet crack tavolrol kihasznalhato biztonsagi hibat tartalmaz.
A hibat nem tervezzuk javitani, mert program igy is fut, a #42 haxxor meg koszoni a farmot.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.
2.6.27-rc2-00389-g10fec20

De erv, mert egy GPL/BSD/egyeb F/OSS licenc kezeleset azert nehezebb elszurni. Hacsak nem figyel arra a progi, hogy ott legyen a "COPYRIGHT" file a helyen (benne az aktualis bleeding edge GPL verzioval), es csinal rola md5sum-ot minden egyes inditaskor. Ezt nem hiszem, hogy barki megtenne, marpedig a nem letezo kodban nem lehet hiba.

----
It doesn't take a rocket scientist to program a computer, it takes a programmer.
honlapkészítés

Mas reszeben valoban lehet bug.
A utorrent pont rossz pelda, az egy zart forrasu win32-es kliens. Az egyetlen dolog, ami a nyilt forrashoz koti, az az, hogy elindul wine alatt. A konkret bug valoban vicces, egy hasonlot mar eljatszottak a winamppal is par eve (ott az id3 tagek kezelesenel volt buffer overrun).

----
It doesn't take a rocket scientist to program a computer, it takes a programmer.
honlapkészítés

hat pedig meglepodnel, milyen extrem dolgokat kepesek gondolkodas nelkul atvenni manyeyeballs urak.

pikans kis reszlet peldaul:

bytesize = nsize * 2;
if (bytesize / 2 != nsize)
return PyErr_NoMemory();

--
"Computer science is no more about computers than astronomy is about telescopes."

Hello, nem tudom most mind a ketten vicceltek-e vagy tenyleg nem ertitek ezt a kodot. Integer overflow eseten tudtommal nincs overflow error, tehat ezt valahogy kezelni kell.

Ha adott x integer, es ezt megszorzod 2-vel akkor ez persze tulcsordulhat, ilyenkor az eredmeny effektive kisebb lesz mint x. Ha le akarod ellenorizni hogy volt-e tulcsordulas akkor csinalhatod azt pl. ami a megadott kodreszletben van.

Szerk: mit gondolsz mit ir ki a kovetkezo program, persze ezek utan mar nem nagyon nehez a kerdes.....

#include <limits.h>
#include <stdio.h>

int main()
{
int a=INT_MAX;
int b=a*2;
if (b/2 != a)
{
printf("gebasz\n");
}

return 0;
}

Azért majd egyszer, ha ennél bonyolultabb programot is írsz és esetleg majd azt mások is használni fogják, akkor inkább ne osztással ellenőrízd le egy potenciális integer túlcsordulást, mert eléggé CPU és időigényes feladat. Inkább használj egy egyszerű összehasonlítást, az kevésbé terheli a processzort, gyorsabban lefut és az emberek, akik használják majd a programodat elégedettebbek lesznek... ;)

Igen, és mint tudjuk a sar + összehasonlítás kevesebb művelet, mint csak simán egy összehasonlítás, igaz? ;)

Mellesleg az egész összehasonlítást is kioptimalizálhatja bizonyos esetben a fordító, de most nem ilyen szintű optimalizálásokról beszélgettünk, meg nem gcc-ről, ugye?

Természetesen nem, az csak denes elkanyarodása, azt a látszatot keltve, hogy a programozók nyugodtan írhatnak szar kódot, mert a fordító majd úgyis biztos rendesen optimalizálni fogja, mintha mesterséges intelligencia lenne és minden emberi agymenést ki tudna javítani...

Az eredeti hozzászólás arról szólt, hogy milyen hülyeségeket képesek átvenni gondolkodás nélkül a fejlesztők.

Akkor most valóban akkora nagy hülyeség volt, hogy ezt kellett pellengérre kellett állítani, vagy az illető tényleg benézte, és lett belőle ez "de, ize... őő... nincs benne a várjá.. őő az optimalizáció!" izzadós - legalábbi innen úgy látszik - magyarázkodás? :)

--
trey @ gépház

ezt kellett pellengérre kellett állítani

Ha jól láttam a kiinduló hozzászólást, akkor csak egy példa volt, ráadásul nem is tőlem, így nem is értem, hogy miért engem kérdezel erről.

izzadós - legalábbi innen úgy látszik - magyarázkodás

Hát ha onnan úgy látszik, akkor érhető, hogy a rendszer programozói papír miért csak mutogatás képpen van, kedves Gábor. ;)

Azért tőled kérdezem, mert te is hirtelen beleugrottál a diskurzusba, az szál indítóját pedig azóta se láttuk.

Válasz pedig még nem jött mindig a kérdésre. Pedig most izgatottan várom, hogy akkor most mi volt az a nagy baklövés, ami miatt ezt ide kellett citálni. Én nem értek hozzá, ezért szeretnék tanulni. Nem hiszem, hogy az optimalizáció, pontasabban annak hiánya miatt volt ez idézve, mert ilyen alapon a világ megírt programjainak 90%-át ide lehetne idézni.

Szóval akkor most mi is volt a nagy probléma? :)

--
trey @ gépház

Az, hogy ha ez a kod csak igy onmagaba all, akkor hulyeseg, es tenyleg arrol szol, hogy 2*2 != 5.
Ha az integer tulcsordulast akarja az illeto tesztelni, akkor azt meg egy rendes koder, aki ilyen kodot importal, siman lecsereli egy if((nsize * 2) /2 > INT_MAX) kezdetu kodra, de meg inkabb valami olyan ellenorzesre, ahol az INT_MAX-tol torteno tavolsagot vizsgaljuk.
Valoban lehet integer overflow problema, de pre-tesztelni nincs ertelme, a helyen kell tesztelni.
Az mar csak hab a tortan, hogy egy integer overflow-ra Py_NoMemory() -val visszaterni enyhen szolva is a vicc kategoria, hiszen nem ez a hiba.
Azt mar meg sem merem emliteni, hogy ha tenyleg memoriafoglalast tesztelunk, akkor azt nem integer overflow-on keresztul detektaljuk, mert annak akarmi oka is lehet. le kell kerni a felhasznalhato mem mennyiseget, es ahhoz kell merni a nsize erteket.

Mondja ezt egy hobbikoder.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

ez a kod onmagaban jo, mert azt, hogy egy signed integer (ami lehet negativ is) 2-vel valo szorzas utan nem csordult tul, igy lehet a legkonnyebben ellenorizni (osztas helyett lehetne eltolas, de tok mindegy, mert egy ertelmes fordito kioptimalizalja).
az mas kerdes, hogy az nsize miert signed (mint paxteam ramutatott), tovabba mar elotte ellenoriztek, hogy pozitiv - viszont ez az idecitalt 3 sorbol nem derult ki, ergo ertelmetlen volt ezt igy idecitalni.

- Use the Source Luke ! -

_szerintem_ egy sizeof hivassal meg lehet tudni, tulcsordulna-e, sokkal egyszerubben, mint ez az osztogatos hulyeseg. Plusz ezt igy 4 sorba szetszedni... Oke, hogy a fordito kioptimalizalja, de muszaly mindig erre jatszani?
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

jo, akkor tenyleg kb. 1 orajellel ez lassabb (kerdes, hogy ez itt eppen egy futasido erzekeny resz-e). viszont ez a modszer mukodik akkor is ha negativ is lehet az esetleg tulcsordulo szam (mondjuk ebben az esetben szerintem nincs errol szo), ezt egy osszehasonlitassal szerintem nem tudod megoldani.

mas kerdes, hogy - mint Trey is felhivta ra a figyelmet - a Replaced altal emlitett "pikans" resznel valoszinu, hogy nem az 1 orajel (pentium4-en 2) vesztesgre gondolt, hanem benezte. te viszont jottel segiteni fikazni az nyilt forrast. ;)

- Use the Source Luke ! -

Aha, ertem, ezek szerint ezt ertetted
http://hup.hu/cikkek/20080812/komoly_vmware_bug_miatt_leallhatnak_a_vir…
alatt? Bocs, de ezt nem sikerult kihamoznom belole.

Egyebkent felesleges most mar az orajelekkel jatszani, az emlitett kod helyes, es kesz. Valamint, mint mar lentebb volt, altalaban is mindig mukodik, nem csak akkor amikor pozitiv az eredeti ertek. Vagy van olyan megoldas ami mindig mukodik, es csak egy osszehasonlitas?

a kod azert 'rossz', mert azt mutatja, hogy az irojanak nem sok koze van a problemahoz, amit megoldani szandekozott. ha megnezed a kod kornyezetet, akkor lathatod, hogy az nsize 'int' (vagyis elojeles, ami meretrol leven szo, eleve tervezesi hiba mellesleg), viszont a replaced altal bemasolt kod elotti resz garantalja, hogy csak pozitiv erteke lehet (legalabbis remelem, hogy a 'pairs' valtozoval nem lehet kitrukkozni). ezek utan jon az ominozus int overflow ellenorzes a 2-vel torteno szorzasra. ertelmes embernel ez nsize > INT_MAX/2 lenne az adott esetben, a kodban meg az, ami... ezek utan, hogy ki mit nezett be, szerintem eleg egyertelmu ;)

En igazan nem akarok ertetlenkedni, de szerinted mennyivel jobb az

nsize > INT_MAX/2

mint a

bytesize / 2 != nsize

? Szerintem egyebkent a

bytesize < nsize

lenne a legjobb ebben az esetben, ezert is kerdezem.

Szerk. ja, ertem, hulye vagyok, az INT_MAX/2 az csak egy konstans. Ok, semmi.

( doszy | 2008. 08. 13., sze – 14:57 )

[off]All your base are belong to us. :D[/off]

( msandor v | 2008. 08. 14., cs – 15:34 )

lehet tévedek, de én már a frissített iso-kat is látom a honlapjukon...

--
by Mikul@s