2010-12-02 11 views
0

Il peut être un peu difficile de tout expliquer sur cette erreur, mais je vais faire de mon mieux. Malheureusement, le code est si grand qu'il serait peu pratique d'essayer de l'inclure. Je suis en train d'écrire un OS académique pour les devoirs (des nachos si vous devez le savoir) et la dernière chose que je devais faire était de mettre en place une exclusion mutuelle dans une carte principale. Pour ce faire, j'ai ajouté un verrou et une variable de condition par page dans la mémoire principale émulée. Après cela, je lance mon code et passe un appel à l'exception (dans un répertoire complètement différent de la carte de base) très bien, mais la deuxième fois que la fonction est appelée je reçois et erreur sur l'appel suivant: r=new Lock("read"); et il lit comme ceci:Échecs de mémoire lors de l'appel

*** glibc detected *** /home/some_other_directories/workspace/nachos3_repo/vm/nachos: malloc(): memory corruption (fast): 0x0805fe20 *** 

Juste pour voir comment il se comporte, j'ai changé l'attribution de ce verrou pour être un extern dans mon fichier système (il y a beaucoup de externs mondial là-bas) et après que je reçois une erreur de SEG l'appel fout.open("old.txt"); que j'ai retracé à travers la pile pour être dans un appel à malloc dans un appel à nouveau.

Ma meilleure estimation est que mon tas devient trop grand mais je ne suis pas sûr que ce soit le cas ou comment le gérer si c'est le cas. quelqu'un peut-il faire la lumière sur ce problème?

+0

Avez-vous essayé Valgrind? –

+1

Vous avez un problème d'écrasement de la mémoire. Quelque part dans votre code C, vous écrivez au-delà de la fin d'un tampon (ou autre) et détruisez les structures de données sous-jacentes que l'exécution utilise. valgrind ou C++ avec vérification des limites activée pour la STL en mode debug. –

+0

Je suis un peu nouveau et j'ai du mal à comprendre toutes les sorties de valgrind, et je n'ai pas beaucoup de temps pour l'apprendre. J'essaie toujours de le regarder cependant. – user381261

Répondre

1

malloc est juste la victime ici. Dans une partie complètement différente du code, vous avez écrit en dehors des limites allouées et avez donc des liens en chaîne corrompus qui sont utilisés par le gestionnaire de tas pour suivre les blocs libres/alloués. Lorsque vous essayez d'allouer ici, le gestionnaire de segments de mémoire poursuit ces listes chaînées et atterrit dans une zone protégée (probablement non allouée). Vous devriez faire une opinion sur vos modifications à d'abord et voir si vous pouvez trouver où vous gribouillez la mémoire.

+0

C'était une mauvaise suppression, quelqu'un m'a aidé à comprendre valgrind. – user381261

+1

Heureux que ça a marché. Votre chance de le retrouver en moins d'une heure ... –