Discussion :

[sylvain52220]

Bonjour,

Je ne sais plus par où attaquer un problème sur lequel je travaille depuis plusieurs jours maintenant.

Une méthode de mon application écrite en C++ modifie le paramètre de type const string & que je lui passe si j'utilise l'appel à cette méthode comme paramètre d'un autre appel (cout dans les exemples ci-après). Je m'explique:

Prototype de la méthode suspecte:
string Class1::Mth1(const string &s);

J'ai essayé différents appels à Mth1 depuis un autre méthode Mth2 de la classe Class1, avec les résultats suivants:

1:
// s1 est un paramètre de type const string & reçu par Mth2
cout << this->Mth1(s1) << endl; // => modifie le contenu de s1

// alors ce qui suit ne pose pas ce problème :
string str = this->Mth1(s1);

2:
// s2 est une constante déclarée et initialisée juste avant l'implémentation de Mth2 (const string s2 = "toto"
cout << this->Mth1(s2) << endl; // => modifie le contenu de s2

3:
string s3 = "toto";
cout << this->Mth1(s3) << endl; // => modifie le contenu de s3

4:
string s4;
s4 = "toto";
cout << this->Mth1(s4) << endl; // => Ok, s4 n'est pas modifié

Quelqu'un aurait-il une piste?

Merci d'avance.

[Noxen]

Salut,

Si ce n'est pas trop long, peux-tu poster la classe et le contenu des méthodes ? Il faudrait avoir une idée des traitements et de la valeur de retour.

Sinon, comment tu constates que la chaîne a été modifiée ? Tu la regardes après l'appel à la méthode ou tu regarde la valeur renvoyée par Mth1() ?

[Davidbrcz]

Une méthode de mon application écrite en C++ modifie le paramètre de type const string & que je lui passe

Impossible, le compilateur t'enverrai sur les roses.

Fait plutôt voir le code incriminé.

[sylvain52220]

Noxen, Davidbrcz,

Merci pour vos réponses.

Lors de nos tentatives pour solutionner le problème, nous avons simplifié au maximum les méthodes que nous pensons le causer. Mth1 en est réduite à:

string Class1::Mth1(const string &s)
{
string r=s;
return(r);
}

Le compilateur ne dit rien, puisque, manifestement (comme dans la méthode originale d'ailleurs) nous ne cherchons pas à modifier la string passée en paramètre.

Pour ce qui est de la détection du fait que la chaine est modifiée, nous affichons sa valeur avec cout et printf avant, après l'appel à Mth1 et même dans Mth1.

Le plus surprenant est que Mth1 produit le bon résultat (dans mes exemple, la chaine attendue est affichée), mais à la ligne d'après, la chaine apparait vide avec printf et apparait altérée avec cout.

Un deuxième appel à Mth1 fait crasher l'application:

Segmentation fault in free_y at 0x90000000032bb14 ($t1)
0x90000000032bb14 (free_y+0x344) e9490008 ld r10,0x8(r9)
(dbx) where
free_y(??, ??) at 0x90000000032bb14
free_common(??) at 0x900000000329ab8
delop.operator delete(void*)(??) at 0x9000000002a5724
string.deallocate__Q2_3std9allocatorXTc_FPcUl(??, ??, ??) at 0x9000000001529c8
_Tidy__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__Fb_75_12(??, ??) at 0x90000000014f7d0
string.__dt__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__Fv(??, ??) at 0x90000000014f61c
Mth2__10DAOStationFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__RCb(0x110ba19d0, ...
main(0x300000003, 0xfffffffffffe778) at 0x101798e98



Autre fait étrange: si après le 1er appel malheureux à Mth1 j'appelle une fonction toute bête :

string toto(void)
{
return("toto");
}

comme suit (toujours dans Mth2):

cout << toto << endl;

L'application crashe et produit un fichier core dont la stack est :

Segmentation fault in leftmost at 0x90000000032b1b8 ($t1)
0x90000000032b1b8 (leftmost+0x8) e8c90008 ld r6,0x8(r9)
(dbx) where
leftmost(??, ??) at 0x90000000032b1b8
malloc_y(0x21, 0x0, 0x110001b88, 0x0, 0x2, 0x75740000, 0x6f, 0x1017f0fcc) at 0x90000000032d380
malloc_common_79_63(??) at 0x90000000032a25c
_Fancy_malloc__FUl(??) at 0x9000000002a7e34
__nw__FUl(??) at 0x9000000002a7b14
UtiDate._Copy__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FUl(??, ??) at 0x10001c174
UtiDate._Grow__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FUlb(??, ??, ??) at 0x10001bd4c
UtiDate.assign__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FPCcUl(??, ??, ??) at 0x10001b814
toto__Fv(0xfffffffffffce40) at 0x100983b3c
Mth2__10DAOStationFRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__RCb(0x110ba2770, 0xfffffffffffd540, 0xfffffffffffd388) at 0x1009840b0
...
main(0x300000003, 0xfffffffffffe778) at 0x101798d38

UtiDate est une classe que nous utilisons dans l'application, mais pas dans la fonction toto() !?!? Je ne comprends pas pourquoi on la retrouve ici!

Any idea?

[Jean-Marc.Bourguet]

Donne un code complet et minimal reproduisant le probleme. En le cherchant, il y a des chances que tu trouves le probleme tout seul

(Mon idee a moi est qu'il y a de la corruption quelque part et vraisemblablement pas dans le code ou le symptome apparait.)

[sylvain52220]

Bonjour Jean-Marc,

C'est bien ce que j'essaye de faire.

Pour l'instant je n'arrive pas à reproduire le problème dans un "petit" programme à part. Je pense aussi à une corruption quelconque et j'ai posté un message car je suis à court de pistes d'investigation: j'aurais souhaité (conscient que c'est difficile avec seulement les éléments que je communique) qu'on me conseille de vérifier telle ou telle chose pour orienter mes recherches.

Merci tout de même.

[Noxen]

Tu utilises quel environnement de développement ? Il pourrait être utile ici d'utiliser le mode pas-à-pas d'un debugger pour repérer exactement à quel moment la corruption des données se fait. Si ça n'avait pas été une classe de la SL, j'aurais peut-être pensé à un problème avec un constructeur ; une fois j'avais naïvement appelé un constructeur paramétré dans un constructeur sans paramètre, pensant que ça allait me permettre d'instancier un objet sans dupliquer du code, le résultat sur les variables membres était purement prodigieux ...