Nous sommes sur HPUX et mon code est en C ++. Nous obtenons
BUS_ADRALN - Alignement d'adresse non valide
Dans notre exécutable sur un appel de la fonction. Que signifie cette erreur? La même fonction fonctionne plusieurs fois, puis soudainement sa caisse de noyau. Dans GDB, lorsque j'essaie d'imprimer les valeurs d'objet, il n'est pas en contexte. Tout indice où vérifier?
4 Réponses :
La plupart des processeurs (pas x86 et des amis .. Le Blacksheep de la famille LOL) nécessite des accès à certains éléments à aligner sur des multiples d'octets. C'est à dire. Si vous lisez un entier de l'adresse 0x04 qui va bien, mais si vous essayez de faire la même chose à partir de 0x03, vous provoquerez une interruption pour être lancée.
Ceci est dû au fait qu'il est plus facile d'implémenter le matériel de charge / magasin s'il est toujours sur un multiple de la taille des données avec laquelle vous travaillez.
Depuis que HP-UX ne fonctionne que sur les processeurs RISC, qui ont généralement de telles contraintes, vous devriez voir ici -> http://fr.wikipedia.org/wiki/data_structure_alignment#risc .
Merci pour la réponse. Dans mon cas, ma fonction renvoie un char. sa ne pas échouer à chaque fois. Je vérifierai votre lien wiki.
@Herman: Je ne vérifierais pas la valeur de retour, qui est généralement adoptée dans un registre. Je vérifierais les arguments à la fonction.
Ma fonction ne prend aucun argument. appel est comme si (ABCD-> FOO () == 'x') // fait quelque chose d'autre // autre partie
En réalité, HP-UX a son propre grand forum sur ITRC et certains membres du personnel HP sont très utiles. Je viens de regarder le même sujet que vous demandez et Voici quelques résultats . Par exemple Le problème similaire a été causé en réalité par un mauvais paramètre d'entrée. Je vous conseille vivement de lire les réponses à une question similaire et si nécessaire pour poster votre question là-bas.
Au fait, il est probable que vous soyez invité à publier des résultats de ces commandes gdb :
Vous avez un problème d'alignement de données. Ceci est probablement causé par la tentative de lire ou d'écrire à travers un mauvais pointeur de quelque sorte.
Un problème d'alignement des données est lorsque l'adresse d'un pointeur de pointe de pointe n'est pas "alignée" correctement. Par exemple, certaines architectures (l'ancienne crayon 2 par exemple) exigent que toute tentative de lecture autre qu'un seul caractère de la mémoire ne se produise que par un pointeur dans lequel les 3 derniers bits de la valeur du pointeur sont 0. Si l'un des derniers 3 bits sont 1, le matériel générera un défaut d'alignement qui entraînera le type de problème que vous voyez.
La plupart des architectures ne sont pas aussi strictes et fréquemment que l'alignement requis dépend du type exact accédant. Par exemple, un entier 32 bits peut nécessiter que seuls les 2 derniers bits du pointeur doivent être 0, mais un flotteur 64 bits peut nécessiter que les 3 derniers bits doivent être 0.
Les problèmes d'alignement sont généralement causés par les mêmes types de problèmes qui causeraient une défaillance de Segfault ou de segmentation. Habituellement, un pointeur qui n'est pas initialisé. Mais cela pourrait être causé par un affectateur de mémoire mauvais qui ne renvoie pas les pointeurs avec l'alignement approprié ou par le résultat de l'arithmétique du pointeur sur le pointeur lorsqu'il n'est pas du type correct.
La mise en oeuvre du système de comme une note latérale, les architectures X86 et X86_64 n'ont aucune exigence d'alignement. Mais, en raison de la façon dont les lignes de cache fonctionnent et pour diverses autres raisons, c'est souvent une bonne idée de la performance d'aligner vos données sur une limite aussi importante que le type de données stocké (c'est-à-dire une limite de 4 octets pour un 32 bit Int). MALLOC et / ou Nouveau est presque certainement correct ou votre programme se bloquerait de manière à ce qu'elle ne le fait actuellement. Je pense donc que l'allocator de mauvaise mémoire est l'arbre le moins probable d'aller aboyer. Je vérifierais d'abord pour un pointeur non initialisé puis un mauvais pointeur arithmétique.
La plupart de ces problèmes sont causés par de multiples dépendances en amont reliant différentes versions de la même bibliothèque.
Par exemple, le GNUSTL et STLORP fournissent des implémentations distinctes de la bibliothèque standard C ++. Si vous compilez et reliez à GNUSTL, tandis que l'une de vos dépendances a été compilée et liée à Stlport, vous aurez chacune une implémentation différente de fonctions et de classes standard. Lorsque votre programme est lancé, la liaison dynamique tentera de résoudre tous les symboles exportés et découvrira des symboles connus à des compensations incorrectes, ce qui entraîne le signal BUS_ADRALN.