Comportement inexplicable dans C. Odd vs Nombre pair de chaînes

Question

J'ai donc un problème que je n'arrive pas à comprendre. Je suis en train d'écrire du code en C. J'ai continué à me retrouver avec des problèmes où la lecture du réseau fonctionnerait au hasard. J'ai finalement retracé le nombre de chaînes dans le code. Je ne peux pas le croire mais je l'ai vérifié assez en profondeur. La base de code est plutôt massive donc je ne suis pas sûr du nombre total de chaînes parité. Cependant je sais que si j'ajoute un nombre impair alors le programme fonctionne, et si j'ajoute un nombre pair il doesnt. Juste pour clarifier quand je dis que cela ne marche pas, il construit et exécute toujours, mais chaque fois que j'essaye de lire n'importe quoi sur le réseau tout ce que je reçois est 0. Quand je travaille, j'obtiens les bonnes données.

Est-ce que quelqu'un a déjà entendu parler de quelque chose comme ça? Ou avez-vous une idée de ce qui pourrait causer cela? Je pouvais voir si la portion de données du programme devenait trop grande et commençait à gêner l'espace de l'autre code, mais le fait que ce soit un truc impair/pair me rend complètement confus.

grâce

EDIT (Ajout de plus d'informations):

La plate-forme est un dispositif conçu sur mesure. la base de code est redboot mais elle a été modifiée de manière significative pour le périphérique personnalisé.

Snipped par exemple:

// Cela fonctionne parce que son nombre impair de chaînes.

char* str1 = "test"; 
char* str2 = "test2"; 
char* str3 = "test3"; 

int i = strlen(str1) + strlen(str2) + strlen(str3); 

......................................

si je devais changer la dernière ligne

int i = strlen(str1) + str(len2); 

afin que str3 s'optimisé par le compilateur alors le code ne fonctionnera plus. J'ai testé cela plusieurs fois avec des longueurs de cordes différentes qui donnent tous le même comportement impair/pair. (Je viens d'être envoyé à un journal de débogage pour qu'il ne soit pas optimisé, rien de fantaisiste n'est fait avec). Edit2: Le code ci-dessus peut être placé n'importe où dans la base de code et provoque le même problème. Peu importe si elle a été exécutée ou non, ce qui me porte à croire que ce n'est pas un débordement de pile.

Answer 1

Voici une estimation.

Supposons que la plate-forme est de 32 bits.

Peut-être que le compilateur aligne certains des structures de données de votre programme en mémoire sur des limites de huit octets. Vous avez tout un tas de pointeurs de chaîne dans votre segment de données et peut-être d'autres choses aussi. S'il y a un nombre impair de chaînes, la prochaine chose qui a besoin d'un alignement de huit octets a quatre octets de remplissage en face de lui. S'il y a un nombre pair de chaînes, il n'y a pas de remplissage. Quel que soit le morceau de données précédant cet objet aligné sur huit octets, il existe un bogue de débordement qui détruit juste le contenu entre un et quatre octets après celui-ci. S'il y a du rembourrage après cette chose, il ne se passe rien de mal. S'il n'y a pas de remplissage, l'objet aligné sur huit octets est zappé.

Answer 2

Je n'ai jamais entendu parler d'un problème comme celui-ci. On dirait que vous êtes très frustré et vous dites que votre base de code est plutôt massive. Si la résolution du problème est importante, je suggère que vous essayez de reproduire le problème avec une plus petite quantité de code. Cela peut aussi vous aider à obtenir des réponses si vous postez des exemples de votre code pour illustrer la question.

Answer 3

temps aléatoire coup de poignard dans le noir ...

Un malentendu commun lors de la lecture de sockets réseau est qu'un read() de 10 octets retourneront les 10 octets suivants. Ça ne va pas. Il renverra jusqu'à 10 octets, et vous devrez peut-être appeler read() plusieurs fois pour obtenir toutes les données dont vous avez besoin.

Answer 4

D'où tenez-vous l'affirmation selon laquelle cela a à voir avec la parité du nombre de chaînes?Si j'essaie d'interpréter ce que vous dites attentivement, cela me dit que de petits changements dans le code vous permettent de déclencher un comportement inattendu.

Odeur semblable au débordement de la pile. Allouez-vous des tableaux ou des chaînes volumineuses sur la pile, puis faites-leur read et write? Dans ce cas, essayez d'allouer/désallouer dynamiquement ces tampons volumineux via malloc/free.

Answer 5

si vous avez somthing comme

char buf[10]; 
long var; 
strcpy(buf, "ganz viel text"); 

vous pouvez ou ne peut pas obtenir une violation de segmentation ou d'un comportement étrange avec la variable "var". Si vous mettez plus de texte de débogage dans votre code, l'éditeur de liens peut réaffecter les variables, ou le compilateur peut faire d'autres optimisations de code, et l'allocation d'espace de réallocation en mémoire.