2010-09-27 6 views
5

Consultez le code suivant:Comprendre ce comportement erratique dans gdb

#include <stdio.h> 
#include <ctype.h> 

char* Mstrupr(char* szCad); 

int main() 
{ 
    char szCadena[] = "This string should print well."; 
    printf("%s\n", Mstrupr(szCadena)); 
    printf("%s\n", Mstrupr("This string should fail.")); 
    return 0; 
} 

char* Mstrupr(char* szCad) 
{ 
    int i; 
    for (i=0; szCad[i]; i++) 
     szCad[i] = toupper(szCad[i]); 
    return szCad; 
} 

Le deuxième appel à Mstrupr ne parvient pas à fonctionner correctement sur linux comme la réception de la chaîne comme littéral (et non pas comme un tableau de caractères). Lorsque le programme complet est exécuté sur gdb, il échoue également, mais lorsqu'un point d'arrêt est ajouté à main et que le programme est exécuté via la commande suivante de gdb, la deuxième chaîne est mise en majuscule et imprimée. Pourquoi? Je crois que cela ne devrait pas l'être, mais mon instructeur insiste sur le fait que cela fait partie du design de gdb.

Répondre

9

Je ne vois pas que cela fait partie du design de gdb. Cela semble être un effet secondaire accidentel; gdb rendait le segment de code accessible en écriture lorsqu'il définissait le point d'arrêt, donc votre code qui écrase les littéraux fonctionne maintenant

En fait, aucun concepteur de débogueur ne ferait délibérément changer le comportement d'un programme par leur débogueur; cela rend le débogage vraiment difficile

+0

C'est probablement quelque chose que les gens de gdb considéreraient comme un bug. Cependant, pour la plupart des utilisations (pas certaines), gdb doit changer de code pour insérer une instruction break pour implémenter un point d'arrêt, ce qui signifie qu'il doit changer cette zone de mémoire pour être inscriptible. Il ne semble pas le changer à ses paramètres précédents. – nategoose

+0

C'est vraiment étrange, d'autant plus que ma version de gcc met tout dans un segment différent, '.rodata' que gdb n'a aucune raison de toucher – Hasturkun

1

Je dois souligner que j'ai recompilé et re-débuggé ce code avec un nouveau gdb (GDB 7.1) et ce comportement n'apparaît plus. Le code apparaît défectueux (erreur de segmentation lors de l'appel de la deuxième fonction), comme il se doit.

+0

sonne comme un bug fixe dans gdb – pm100

+0

Oui. Je le crois. – andandandand

Questions connexes