Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 62

Newsletter 62

by Z98 on 2009-07-21
translated by Gabriel ilardi on 2009-07-21

Corruzione PSEH

Nei sistemi operativi NT, Structured Exception Handling è utilizzato per salvaguardare le prove dei buffer di memoria in usermode e di memoria paginabile mentre si è in kernel mode. Questo requisito è stato la causa che ha motivato la creazione della libreria PSEH da KJK::Hyperion visto che GCC non ne fornisce il supporto. Poiché l'ultimo tentativo di aggiungere SEH a GCC è fallito, ReactOS dipende da PSEH. Recentemente, il team ARM aveva introdotto del codice che aveva esposto un bug molto brutto nella libreria PSEH e la sua investigazione ha portato KJK a scoprire un altro bug mentre analizzava il codice. Entrambi erano piuttosto seri, poiché finivano per causare grandi problemi quando venivano sollevate delle eccezioni.

Il primo bug riguardava i blocchi annidati try/catch, dove se veniva sollevata un'eccezione e colta nel blocco interno e un'altra in quello esterno, il codice saltava non nella sentenza di catch del blocco esterno ma in quella interna. L'esecuzione quindi riprendeva dal blocco interno nuovamente risultando in un loop infinito. Quello che succedeva effettivamente era che il trylevel del blocco interno non veniva "poppato" quando il codice usciva dal blocco rimanendo nello stack, cosa che faceva pensare a PSEH che ancora si trovava nel blocco interno. Questo rendeva chiaramente il sistema operativo inutilizzabile quando succedeva, che è quello che è successo dopo che si sono abbinati il commit del team ARM e un test nella suite di test automatica sparando il bug. Con l'aiuto di Stefan Ginsberg, KJK è riuscito a trovare la causa del bug nei blocchi annidati try/catch e i test automatici funzionano nuovamente.

Il secondo bug è in qualche modo simile al primo, nel senso che il frame di esecuzione dell'eccezione non veniva rimosso dallo stack, cosa che aveva un risultato completamente random. La cosa peggiore è che il bug poteva essere scatenato senza i blocchi annidati try/catch quindi anche se non impallava il sistema operativo, in sostanza risultava in una corruzione random dello stack che poteva influire su altre cose ed eventualmente causare corruzioni difficili da rintracciare. Siccome questo succedeva tutte le volte che veniva sollevata un'eccezione in SEH, non è da stupirsi se è la causa di molti crash random di cui ha sofferto ReactOS dall'introduzione di PSEH2. Ironicamente, c'è stato un problema identico in PSEH1 con la stessa fix. La suite di test PSEH di KJK ha aiutato anche, una volta che ha aggiunto i controlli di integrità che mancavano. Certo, aggiungere quei controlli ha dato come risultato che il suo codice fallisse la maggior parte dei test fino a che non ha corretto il bug.

XLATEOBJ

XLATEOBJ è una struttura di dati con qualche funzione associata che aiuta a convertire colori tra superfici diverse, come ad esempio da una bitmap al formato di colori di un display. Siccome questa operazione avviene tutto il tempo è importante che sia veloce. L'implemtazione in ReactOS purtroppo non lo era, con una delle sue funzioni usando una serie di istruzioni if/else per decidere come fare le conversioni. Timo Kreuzer le ha sostituite con delle funzioni callback che fanno solo quanto necessario, con qualche funzione ottimizzata per formati speciali. Un'altra modifica che Timo pensa di fare è invece che allocare dinamicamente XLATEOBJ dal pool paginato ogni volta che avviene un'operazione di bitblt, è allocarlo dallo stack.

Normalmente quando si converte tra formati di colori si fa una conversione pixel per pixel. Come lo suggerisce il nome, quando si usa un pennello modello, viene usato un piccolo modello che si applica alla superficie di destino. Prima di usare il pennello, viene fatta una chiamata al driver da GDI tramite la funzione DrvRealizeBrush per convertire il modello di pennello al formato di colore della superficie destino. Questa operazione si chiama "realization". Allo stesso tempo, GDI può creare la sua realization di pennello se il driver informa che la scheda non supporta questa conversione. ReactOS non lo faceva previamente ma Timo ha fatto le modifiche nella sua copia di lavoro e dopo assicurarsi che non ci saranno problemi farà il commit.

Arwinss

Aleksey Bragin ha creato recentemente un branch chiamato Arwinss, che sembra rappresentare un'altra riscrittura del sottosistema Win32 in un modo o nell'altro. Ha anche mandato un'email con i particolari del perché l'ha creato e perché ha adottato questo approccio. Il motivo risale alla frustrazione che prova Aleksey con l'attuale sottosistema Win32 e i suoi tanti bug. Mentre tanti altri sviluppatori hanno lavorato sodo e tanto cercando di farlo funzionare correttamente, ci sono ancora bug grossi e altrettanto vecchi. Tanti di questi sono dovuti a degli hack e implementazioni non corrette del passato e sistemarle vuol dire in sostanza riscrivere il sottosistema. Aleksey quindi ha deciso di portare le cose un passo più in là e ha reimplementato il tutto.

C'è una quantità sostanziale di codice Wine nel branch, importato dall'ultima versione. La differenza invece questa volta è che l'architettura Wine è rimasta intatta. La gerarchia delle chiamate in Windows può essere sorprendentemente complessa, la maggior parte delle quali non è duplicata in Wine. Aleksey ha scelto di continuare questa semplificazione e condensare i livelli. Ha creato un componente win32k per il lato kernel del sottosistema significativamente più piccolo, di nuovo chiedendo in prestito qualche codice da Wine per facilitare l'interfacciamento con le librerie usermode di Wine ma aggiungendo le sue proprie modifiche per fare si che il tutto funzioni in un sistema operativo NT. Queste modifiche saranno probabilmente quelle più controverse. Attualmente usare il branch, è nelle parole di Kamil Hornicek, sentire che si sta usando ROS 0.1.0. La visualizzazione del testo è completamente disallineata ed è tutto ammassato, il problema della conversione di colore fa diventare marroni le barre di titolo. Si spera che migliori man mano che si mettono insieme i pezzi, ma la funzionalità sarà ridottissima fino ad allora.

Qualche sviluppatore ha commentato sul lavoro di Aleksey e non tutti lo condividono. Timo Kreuzer ha sottolineato che a lungo termine, questo rischia di ferire lo sforzo di implementare correttamente il sottosistema Win32. Timo è uno degli sviluppatori che sostengono un'implementazione corretta che duplica completamente non solo l'interfaccia Win32 ma anche il design del sottosistema stesso assieme ai suoi strati associati. Mentre questo può sembrare come una grande quantità di lavoro inutile inizialmente, Timo ritiene che il risultato sarà un sistema che si comporta molto più fedelmente all'originale di quanto si possa comportare Wine.

Il piccolo progetto di Aleksey probabilmente creerà un po' di rumore, al meno fino a quando non potrà essere conciliato con le preoccupazioni che gli altri sviluppatori potrebbero sollevare. Allo stesso tempo, offre la possibilità di un inizio pulito quindi l'implementazione parte correttamente da capo senza hack. Solo il tempo dirà se finirà per funzionare o meno.