Ny & Bättre Google Toolbar för Firefox + Problem i Chrome + Farlig (?) minneshantering i Vista för OpenSSL

2/10/2009

Om ni har missat det har Google kommit med en ny Google Toolbar till Firefox. Denna är mycket bättre därför att den ger samma typ av användbara default-sida för nya flikar man öppnar som Google Chrome har:


Notera att delar av skärmdumpen har tagits bort. Sedan blev det en skärmdump av bildprogrammet Gimp då jag tänkte fel.

Jag gillar verkligen det där. När man sett det är det så självklart men själv har jag tänkt på att det är något jag skulle ha användning av innan jag såg det första gången i Chrome. Det är svårt när man vant sig vid något många år att inse att det kan förbättras. Duktigt av den som kom på det. Väldigt användbart!

Chrome: Diverse problem

Google Chrome gillade jag förövrigt verkligen när det kom till gränssnitt. Jag blev dock hur som helst tvungen att sluta använda den ändå tillsvidare. Min användning av webbläsare inkluderar många fönster med många flikar som är igång flera dagar. Det orkade inte Chrome som typiskt tvingade fram omstarter. Trots att detta var besvärande höll jag ut ett tag just därför att gränssnittet är tilltalande enkelt och i år är det enkelhet som gäller för hela slanten:

Förändrad minneshantering i Microsoft Vista

Problemet med Chrome är rent spekulativt ett problem som inte finns om man kör på Linux. Jag kör just nu Microsoft Vista (men ska över till Ubunta så fort jag får tid). Grejen med Microsoft Vista är att de har ändrat hanteringen av applikationer som "behöver" köras i "16-bitars minnesutrymme" (eller hur man ska kalla det korrekt).
TYDLIGGÖRANDE: Det där var ett väldigt dumt sätt att uttrycka det av mig. Problemet är naturligtvis mycket bredare och rör potentiellt allt som allokeras annat än "korrekt" genom WIN32 api:et (såvida om man inte gör det är väldigt försiktigt). Heller inte som jag såg nu påstås av diverse personer på nätet är det begränsat till applikationer som exekveras uteslutande i dos-promptar. Så vitt jag kan se kan det här röra objektfiler, dll m.m. genom samma problematik. Däremot kommer man naturligtvis för de flesta applikationer där detta kan vara ett problem just vara applikationer som körs just där. Men vad jag inte vad vet om Microsoft Windows går att samla i en väldigt stor behållare av något slag.

Chrome som jag diskuterat tidigare är ju fylld av ett antal C-bibliotek som funnits ett antal år och jag spekulerar att ett (eller kanske fler) kan beröras av detta men jag har inte mjukvara på Vista för att kontrollera om så är fallet. Hur som helst är detta fallet innebär det att berörda moduler får begränsat maximalt minne de kan allokera om man inte var medveten om detta och hanterade det. Då kommer de förr eller senare bottna ut och har man inte programmerat defensivt får man "underliga" problem.

När jag nu sitter med en massa Chrome-fönster med 10 - 30 flikar i varje och har datorn igång flera dagar slår det kanske till? Men det är en ren gissning. Det finns massor av annat som kan vara orsaken till problemet. Grejen var dock att jag inte såg några tecken på minnesläckage eller att något loopade oändligt.

Använd alltid din egen malloc

Själv när jag fortfarande programmerade C implementerade jag alltid min egen malloc som ligger ovanför den "riktiga" bör det kunna (om man gör det snyggt) hantera de flesta oförutsedda minnesproblem gracefull. Vidare om man gör på det här sättet blir det naturligtvis också mycket lätt att lösa problemet så att det inte uppstår (allokera "rätt" typ av minne och slipp minnesbegränsningen).

Slutligen vilket är den viktigaste anledningen är att man kan sätta stopp för ett antal minnesproblem som lätt ger säkerhetsproblem på en punkt trots att man använder många helt olika C-bibliotek. Du allokerar t.ex. minnen i stora buntar och lämnar ut vad övrigt begär. Skriver de över, missar att deallokera o.s.v. gör det ingenting för det har ju din egen malloc hantering för. Och du skriver ju över minne när något anropar dealloc så att ev. känslig information inte ligger och skräpar i onödan. Missar något att göra dealloc skrivs det ju över ändå när din dealloc slutligen ska "dö" och du anropar death eller vad du nu kallar din funktion.

Dessutom får man ju upp prestandan genom att du går ifrån en massa onödiga malloc och dealloc genom att återanvända minne. Fast det har knappast någon betydelse längre med dagens hårdvara på hemdatorer (dock osäker på vad som gäller krävande dataspel, bildbehandling, filmbehanding och sådant men för bignumber t.ex. för RSA gör det inte längre någon mätbar skillnad jag märkt). Jag kan dessutom tänka mig att moderna kompilatorer inför sådana här optimeringar själva ännu bättre än vad jag (och de flesta) klarar att göra själva. Ett litet tips i alla fall...

Lite sådant diskuterade jag ju förövrigt tidigare i:

Att kompilera OpenSSL på Vista

Faktiskt har jag en del andra "problem" med Vista när det kommer till saker som är "nytt". Alltså jämfört med Microsoft Windows 2000 server som var det sista jag tittade på (._.)

Bland annat fick jag ge upp på att kompilera OpenSSL till Vista. Det var helt enkelt inte värt tiden det kändes som inläsning av Vista hade krävt för att göra en bra kompilering som orkar tester med mer ovanliga situationer. Faktiskt måste jag säga att flera av de problem jag upplevde fanns är lätt oroande givet säkerhet och stabilitet för applikationer som använder OpenSSL och körs på Vista.

Detta är huvudanledningen till att jag tänker installera Ubuntu när jag får tid. Så att jag kan slutföra testningen av SSL i Chrome:

Vet du inte vad Ubuntu är kan du läsa mer om det nedan:

Kort är Ubuntu den Linux-distribution som är mest het just nu. Den sägs prioritera användbarhet och stabilitet (jag har inte prövat den än). I USA har den snabbt blivit populär och uppskattad.

Mer jag vill ha i Chrome

Mer jag inte gillade i Chrome och som är viktigt för mig var:

  • Det går inte att söka i formulär.
  • Krashar datorn eller man gör panik omstart / bryter strömmen återställer Chrome inte text i formulären.

Båda dessa saker hanterar Firefox numera klockrent.

Fast sådant här löser sig säkert med kommande versioner. Det går inte att få allt klart från början med en webbläsare. Hade Google kört den strategin hade de gissar jag fått stora problem eftersom många problem upptäcks effektivt först när folk i bredare lager börjar använda webbläsaren. Så blir det mycket att fixa på en gång samt att risken för allvarliga defekter blir högre.

3 kommentarer
Anonym sa...

Jo jo det är ett bra tips.

När minnesfelet ligger under din Malloc. Blir det inte trots det? Hur meddelar man upp om anroparen inte kontrollerar felmeddelande på malloc? Ofta gör ju koden inte det.

2009-02-10 21:18
Anonym sa...

För detta:
"Blir det inte trots det?"

Antar jag att du menar:
Blir det inte trots det fel?

Jo då kan du ju få "underliga" problem givet att du inte har någon hantering att passa upp problemet ovanför biblioteken.

Du måste ju också kapsla in gammal C-kod och dylika moduler.

Och så hur får du upp meddelandet förbi biblioteken som anropat din malloc när denna detekterar allvarliga problem och inte kan lita på att anropare hanterar det.

Tja...
I C++ verkar väl exceptions lämpligt? Fast det jag har programmerat väldigt lite i C++ så jag vågar inte säga för mycket här.

I C använder du longjmp i setjmp.h. Longjmp har på goda grunder dåligt rykte därför att många missbrukar det för snusk-programmering. Men just för sådana här situationer är det tycker jag en vettig lösning.

2009-02-10 21:22
Anonym sa...

PS

Sedan innan du ens tänker på att använda longjmp måste du ha dj***ligt full förståelse av hur stackframe fungerar. Annars går det åt he***te.

Men det finns ju färdiga lösningar för inkapsling av osäkra moduler.

2009-02-10 21:47

Kommentera