Mémoire (sbrk) Déplacement aligné de 16 octets sur l'accès au pointeur

Question

J'ai écrit un allocateur de mémoire raisonnablement basique en utilisant sbrk. Je demande un morceau de mémoire, disons 65k et le découper au besoin pour les variables demandant de la mémoire dynamique. Je libère la mémoire en l'ajoutant au bloc 65k. Le bloc 65k est dérivé d'une taille d'union de 16 octets. Ensuite, j'aligne le bloc le long d'une limite de 16 octets pair. Mais je reçois un comportement inhabituel. Accéder à la mémoire apparaît bien car j'alloue et commence à remplir mes structures de données acceptent que sur un de mes appels de fonction, je passe un pointeur vers une variable membre dans une structure globale mais l'adresse de l'argument pointeur ne carte directement à l'adresse de ce membre.

Par exemple, l'adresse réelle de ce membre particulier se trouve être: 0x100313d50 mais lors de l'exécution d'une fonction particulière (rien de spécial) l'adresse du membre est représentée comme 0x100313d70. À l'intérieur du débogueur, je peux interroger l'adresse réelle et elle apparaît correcte quand à l'intérieur de la fonction où cela se manifeste. Ce n'est pas le premier membre qui est accédé non plus, c'est le troisième, donc deux accès mémoire précédents sont bien, mais pendant le troisième accès, je vois ce décalage inhabituel.

Est-il possible que j'accède à cette mémoire via un bloc mal aligné? C'est possible mais je m'attendrais à recevoir une exception SIGBUS (puce SPARC). Je compile en utilisant -memalign = 16s donc il devrait SIGBUS au lieu de piéger et de corriger le désalignement.

Toutes mes structures sont complétées sur un multiple de 16 octets: sizeof (structure)% 16 = 0. Quelqu'un at-il déjà eu l'expérience de ce type de comportement? De manière générale, quel type de choses/choses/etc. peut provoquer un pointeur pour représenter une adresse de mémoire de manière incorrecte?

Cheers, Tracy.

Solaris 10, langage SunStudio-12, langage C sur processeur SPARC moderne (au cas où cela serait utile).

Answer 1

Je pense que je devrais répondre à ma propre question si quelqu'un d'autre a un problème similaire. La raison pour laquelle l'adresse de mémoire a été décalée est qu'un appel antérieur à une fonction d'utilité a accidentellement écrasé la méta-adresse de la structure globale réécrivant ainsi la méta-adresse de ce bloc afin que les recherches sur ce bloc soient décalées. les données réelles résidaient toujours dans le bloc d'origine.

En termes simples, j'ai écrit passé mon tampon. Puisque je distribue de la mémoire à partir de la queue, l'écrasement ferait disparaître ma méta-adresse si nécessaire pour ma structure globale (ou autre). Maintenant, je sais à quoi ressemble un comportement indéfini.