Comment déterminer pourquoi une tâche détruit, VxWorks?

Question

J'ai une application VxWorks s'exécutant sur ARM uC.

D'abord permettez-moi de résumer l'application; L'application comprend une pile tierce et une application de passerelle. Nous avons implémenté une couche d'abstraction du système d'exploitation pour prendre en charge l'indépendance du système d'exploitation.

La pile sous-jacente possède sa propre fonction de contrôle de gestion de la mémoire & qui contient des blocs de mémoire dans une liste à double liaison.

Par exemple; nous n'effectuons pas directement malloc/new, free/delege. Au lieu de cela, nous appelons les routines de la couche OSA et il récupère la mémoire de l'OS et la place dans une liste puis retourne cette mémoire à l'application (routines: XXAlloc, XXFree, XXReAlloc)

Et lors de la libération de la mémoire, nous utilisons à nouveau XXFree.

En fait, ce bloc est une struct qui a

indication des numéros -Magic le début et la fin du bloc de mémoire -size que l'utilisateur a demandé attribué -size en réalité due à l'alignement question des pointeurs précédent et suivant - pointeur sur le morceau de mémoire renvoyé à l'application. lien registre qui montre où dans l'application xxAlloc est appelée.

Avec cette pile de structure de bloc peut vérifier si un bloc est corrompu ou non.

Nous avons aussi PTHREAD qui est la bibliothèque de Linux porté que nous utilisons pour -create/mettre fin à des fils (actuellement il y a 22 fils de discussion) -synchronization objets (événements, mutex ..)

Il est la tâche principale appelé par taskSpawn et plus tard cette tâche a créé d'autres threads.

c'était une description de l'application et de son interface VxWorks.

Le problème est:

l'une des tâches devient soudainement détruite par VxWorks donnant aucune information sur ce qui ne va pas. J'ai aussi un débogueur jtag et il frappe la routine taskDestoy() de VxWorks mais la pile des appels ne donne aucune information ni PC ni r14.

Je me méfie de la routine spécifique dans le code où xxAlloc énorme est fait mais le problème se produit très sporadique ne donnant aucune indication que je peux le mapper au code source.

Je pense que l'OS détecte et exception et exécute sa manipulation silencieusement.

toute aide serait grande

ce qui a trait

Answer 1

Il a été résolu.

J'ai fait un test isolé. Alloué 20 Mo avec malloc et memset avec 0x55 et le fil arrêté de mon application.

Et j'ai écrit un autre thread qui vérifie mes 20 Mo si des données autres que 0x55 est écrit.

Et quess quoi !! un autre thread qui appartient à d'autres composants du processeur (quelqu'un d'autre les a développés) écrit mon espace alloué.

Merci 4 votre aide

Answer 2

Si vos sorties de travail, taskDestroy() est appelée. Si vous vous méfiez de l'énorme xxAlloc, vérifiez que le code d'allocation n'appelle pas exit() lorsque la mémoire est épuisée. J'ai été mordu par ce comportement dans un tiers OSAL avant.

Answer 3

Vous semblez déboguer après l'intégration; Cela peut être un sacré boulot. Je suggère de casser le problème en plus petits morceaux.

processus

1) vous pouvez obtenir plus de perspicacité en instrumentant le code et/ou en utilisant VxWorks intrumentation (selon la version). Cela vous permet d'avoir plus de visibilité sur ce qui se passe. Assurez-vous de tout enregistrer dans un fichier, afin de revenir dans le temps à partir du point où la tâche se termine. L'instrumentation est un investissement rentable car il sera utile dans plus d'occasions. Crochets intéressants dans VxWorks: Taskhooklib

2) l'allocation de mémoire/désallocation est une fonctionnalité très fondamentale. Ce serait mon premier candidat pour un test approfondi (unité) dans un environnement multi-thread bien défini. Si vous avez fait cela et qu'aucune erreur n'est trouvée, je commencerais par regarder pourquoi le tas est terminé.

autres causes possibles

Une tâche se termine également lorsque le travail est fait .. il peut donc être un retour causée par une boucle pas si sans fin. Surtout si c'est toujours la même tâche, ce serait ma conjecture.

Et certaines versions de VxWorks ont un support MMU qui doit être pris en compte.