Home | Informazioni | Community | Sviluppo | myReactOS | Contattaci
|
Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 58Newsletter 58by Z98 on 2009-05-16 UniATAIl driver Universal ATA è stato segnalato spesso come una via per risolvere questioni fastidiose in ReactOS, come la mancanza di supporto per SATA e il limite di spazio rilevato da ReactOS di 8G. Siccome tutte e due le cose sfiorano l'assurdo per i tempi correnti, la loro sistemazione era di priorità elevata. Alcune questioni impedivano il passaggio permanente a UniATA, Aleksey Bragin è riuscito a risolverne alcune. La questione più importante era il fatto che UniATA non rilevava i CD-ROM su hardware reale, che Aleksey è riuscito a sistemare risalendo ad un problema di timing. Lo sviluppatore di UniATA aveva deciso di abbassare il tempo di attesa per diverse operazioni, il che comportava che certi controller non potessero cambiare stato in tempo. Aleksey ha modificato i tempi di attesa per farli concordare con quelli nel vecchio driver atapi e adesso i drive vengono rilevati correttamente in hardware reale. Un'altra questione non risolta ancora è il fatto che UniATA non funziona in VirtualBox. La causa è sconosciuta al momento, ma è il prossimo problema da risolvere nella lista di Aleksey. topPoolCome parte dello sforzo di cercare di capire dove avvengono le corruzioni, Aleksey ha anche fatto un controllo duplice dell'utilizzo del pool di memoria. Il pool è sostanzialmente un modo di allocare memoria per il kernel e i driver, e può essere paginata (scritta nel disco) e non paginata (sempre in memoria). Aleksey ha lavorato su una nuova implementazione e come parte di essa ha scritto quello che in sostanza è un debugger per il pool, in grado di controllare overflow nella lettura o la scrittura di pool allocati. Eseguendolo, ha scoperto un overflow di lettura nel manager PnP. Lo strumento non rileva ancora letture o scritture in underflow, quindi quelle potrebbero essere ancora in giro. Al meno in futuro, il team avrà uno strumento per assicurarsi che non si commetteranno più errori di quel tipo. Tutto ciò è in preparazione per una nuova implementazione del pool sulla quale Aleksey ha lavorato ma che non ha potuto integrare perché ReactOS va in crash con il nuovo codice. Fortunatamente con il debugger può rintracciare la causa. Aleksey ha suggerito anche un debugger per l'heap, ma potrebbe rilevarsi difficile, considerando che le le allocazioni nell'heap, sono molto più frequenti. Per inciso, Aleksey ha risolto anche una questione con l'USB che stava creando problemi su hardware reale. Il codice USB stava cercando di rimuovere un puntatore da una lista concatenata inesistente, il che finiva per corrompere il pool. Questo sarebbe un esempio di errore di underwrite che il debugger del pool non è ancora in grado di rilevare. topPiù MemoriaNel processo di risolvere un bug esposto da OllyDbg, Michael Martin ha sistemato accidentalmente l'installazione di Mono. Le ragioni precise per cui entrambi OllyDbg e Mono si bloccavano con questo bug sono ancora incerte, ma Michael è sicuro che è stato risolto. Quello che succedeva era che OllyDbg chiamava una serie di funzioni, iniziando con CreateFileMappingA. Il punto d'interesse è nelle dimensioni usate per decidere quanta memoria allocare per la creazione. OllyDbg dopo chiamava MapViewOfFile, e lì è dove le cose potevano andar male. La funzione MapViewOfFile e quelle che lei chiama cercavano una struttura di dati SEC_IMAGE che poteva oppure no essere stata identificata da CreateFileMapping e le funzioni che chiamava. Se la trovava, prendeva le dimensioni specificate in essa e le arrotondava perché fossero allineate alle dimensioni della pagina. Se non trovava SEC_IMAGE, la funzione si tirava giù le dimensioni dalla struttura FileObject creata dalla chiamata in catena di CreateFileMapping. Questo valore però non era arrotondato. Questo causava problemi quando OllyDbg chiamava la terza funzione in questa sequenza, VirtualQuery. Questa funzione fornisce informazioni su un'area di memoria, comprese le dimensioni. OllyDbg apparentemente si aspettava che le dimensioni fossero allineate alla pagina e non prendeva bene il ricevere dimensioni non allineate. Michael originariamente non si è reso conto che l'arrotondamento non avveniva e aveva fatto dei test in Windows XP. Lì ha notato che VirtualQuery restituiva sempre una dimensione allineata alla pagina, quindi ha rintracciato in ReactOS dove non avveniva questo allineamento e ha trovato il bug. Nessuno è sicuro su come questo incidesse su Mono, poiché nessuno ha cercato di capire cosa desse problemi a Mono. Tutti i tester sono sicuri però che dopo il fix di Martin, sono riusciti ad installare mono. top |