Bugs de SOS
Merci d'envoyer tout rapport de bug à la
mailing-list de SOS.
Articles 1 & 2
Bug potentiel dans strzcpy()
Si le paramètre
len est nul (ou négatif), alors il y a débordement de buffer dans
strzcpy().
Voici
le patch qui corrige ce bug. Merci à Brice Arnould pour avoir remarqué le bug.
[Corrigé à partir de l'article 3]
Article 2
Erratum sur la figure 4 du Linux Mag 63
A gauche, il faut lire "
cs ... gs" au lieu de "
ecs ... egs".
Oubli d'indiquer l'exception faute double dans l'IDT
A propos de l'exception "faute double", nous écrivons :
Pour cette exception, nous définissons une routine de traitement particulière en assembleur, pas modifiable, et qui fait le maximum pour qu'aucune faute triple ne puisse avoir lieu
Bon, c'est bien beau, mais en plus de la définir cette exception, il faut l'indiquer dans l'IDT... Et ça nous avions oublié de le faire.
Voici
le patch qui corrige cet oubli.
[Corrigé à partir de l'article 3]
Article 4
Erratum sur un exemple numérique
Dans l'exemple numérique portant sur l'adresse 0xA81100C, il y a erreur dans le texte et dans les figures. Il faut lire 0xa81800c et non pas 0xa811800c (erreur figure) ou 0xa81100c (erreur article). Dans ce cas, les valeurs 42, 24 et 12 pour les index de PD/PT et l'offset sont correctes.
[Corrigé dans la version en-ligne de l'article]
Article 5
Erreur dans lookup_range() de kmem_vmm.c (15/11/2004)
La fonction
lookup_range() n'utilise pas les tables de traduction pour accélérer la récupération d'un range à partir d'une adresse virtuelle. Pire, si la page n'est pas mappée en RAM, la fonction plante lamentablement. Tout ceci parce que le test dans la fonction est incorrect et que la fonction
sos_physmem_get_kmem_range() ne prend en parametre que des adresses alignées sur la taille d'une page. Un autre bug potentiel se cachait dans la fonction : on ne testait pas si l'adresse recherchée n'était pas
en dehors du range le plus proche.
Voici
le patch qui corrige cette erreur.
[Corrigé à partir de l'article 6]
Articles 1 à 5 inclus
Non conformité au standard multiboot (16/11/2004)
Le standard multiboot dit (entre autres) :
"load_addr must be less than or equal to header_addr."
Or dans sos ce n'était pas le cas. Merci à Nicolas Duboc pour sa relecture attentive !
Voici
le patch qui corrige cette erreur.
[Corrigé à partir de l'article 6]
Article 6
Erratum article Linux Mag : En page 21, sur la figure 7, l'ordre des registres sauvegardés par le début de
sos_cpu_kstate_switch en rose est
incorrect. Il faut lire, du haut vers le bas :
Eflags, CS, EIP, Error code et non Eflags, EIP, CS, Error code. La même erreur est présente sur la figure 11, page 24. Merci à
Krys de nous avoir signalé le problème sur la liste SOS.
Erratum article Linux Mag : une erreur de mise en page a remplacé un bout de programme C par une commande
hdparm en bas de la page 18. Le code C qui devait s'y trouver, et qui permet de comprendre le bout de code assembleur correspondant est le suivant :
int foo(int a, int b)
{
int c;
int t[12];
c = a + b;
return c;
}
int bar(int d)
{
int e;
e = d + 2;
e = foo(e, 12);
return e;
}
Article "6 et demi"
- Un petit bug s'est glissé dans la démo des souris. Voici le patch qui corrige le bug.
- Un exemple typique de problème corrigé de la mauvaise façon. On testait le non-dépassement de pile sur le contexte du thread qui se termine, ce qui est incorrect si le contexte du thread qui se termine n'avait jamais été encore sauvegardé (par une interruption ou un bloquage) : on pouvait donc détecter des débordements de pile là où il n'y en avait pas eu, tout simplement parce que le thread n'avait jamais été interrompu ni bloqué. La correction initiale (celle dans GLMF de Février) consistait a forcer un changement de contexte vers le thread idle dans main.c... Le vrai raisonnement consiste à dire qu'on ne doit vérifier le non dépassement de pile que sur les threads endormis. Dans notre cas, quand un thread se termine, il faut donc faire la vérification de non dépassement de pile sur le prochain thread à élire et pas le thread en cours. Voici le patch qui corrige le bug (valable pour les versions 6.5 et 6.75 du code).
[Corrigés à partir de l'article 7]
Articles 1 à 7.5 inclus
Le noyau peut devenir assez gros, trop gros pour tenir sur une disquette. Voici
un patch qui :
- enleve tous les symboles, y compris les symboles de debuggage, dans le noyau copié sur disquette
- compresse le noyau. Grub se chargera de sa decompression au vol
- pour les applications utilisateur (articles 7 et suivants) : enleve tous les symboles, y compris de debuggage, des programmes utilisateur
Pour debugger le noyau, utilisez
gdb avec le fichier
sos.elf. Pour naviguer dans le code assembleur des applis utilisateur, utilisez
objdump avec les fichiers
userland/myprogX. Leur variante avec l'extension
.strip (
sos.elf.strip et
userland/myprogX.strip) correspond à la version sans les symboles.
Merci à Cyril Dupuit et à s[e]th & h[o]lth pour nous avoir signalé ce bug apparaissant sur Mandriva 10 et Gentoo.
[Intégré dans la mise à jour disponible au SOSDownload ]
[Corrigé à partir de l'article 8]
Article 7.5
Sous
bochs, il se peut que les applications utilisateur ne se lancent jamais. Cela vient du fait que l'ordonnanceur avec partage de temps ne fonctionnait pas convenablement a cause d'une incoherence entre les structures de donnees (utilisation d'unions) et les fonctions qui les utilisaient. Ce bug existe aussi sur qemu et sur machines réelles mais n'est pas visible parce qu'elles sont plus rapides que bochs.
Appliquez
ce patch pour corriger ce problème.
Update: ajouter -O a la fin de la définition de la variable CFLAGS dans Makefile et userland/Makefile. Une autre solution est de changer la valeur de la variable de configuration
ibs de bochs (mettre
600000).
[Intégré dans la mise à jour disponible au SOSDownload ]
[Corrigé à partir de l'article 8]
Article 7.5
Des ecrasements de données ou des violations d'assertions sur les compteurs de références des pages physiques peuvent se produire. Cela est dû à une gestion incorrecte des pages physiques dans le "
driver"
zero qui permet de mapper des pages vides à la demande, avec partage. Appliquer
ce patch pour corriger le problème.
[Intégré dans la mise à jour disponible au SOSDownload ]
[Corrigé à partir de l'article 8]
Articles 1 à 7.5
Le script qui fabrique la disquette de boot en utilisant Grub (
support/build_image.sh) ne détermine pas correctement l'emplacement de Grub sur certains systèmes Linux. Karim Dridi propose
ce patch pour régler le problème.
[Corrigé à partir de l'article 8]
Articles 2 à 8
Lors de l'initialisation du registre
gdtr, on fournissait une structure qui n'était pas correctement alignée en mémoire. Ce
patch corrige le problème et un autre : certains champs de la GDT n'étaient pas explicitement positionnés à 0 (le compilateur,
gcc s'en charge par défaut). Merci à Romain de nous avoir signalé ces problèmes.
Update : le patch contourne également un
bug des binutils 2.16.
[Corrigé à partir de l'article 9]
Articles 1 à 8
Vous allez rencontrer des problèmes pour compiler SOS dans un répertoire contenant des espaces et/ou des caractères bizarres (dollars, apostrophe) du genre
/tmp/Quë lâ vîe êst b€lle avec $ôs/l'article 8
Voici
le patch (article 8) qui corrige ce problème.
[Corrigé à partir de l'article 9]
Articles 6.5 à 9
Il y a une erreur dans
sos/ksynch.c qui fera que
mutex_lock peut échouer intempestivement. Voici
le patch qui corrige ce problème.
