Bonjour,
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6
trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de
vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà
présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL.
Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien...
Et 2ème question, si ce n'en est pas, comment faire ?
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6.
Connaitriez-vous un autre outils (à part BC7...)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
David Brabant
"amerio" wrote
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien... Et 2ème question, si ce n'en est pas, comment faire ? Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6. Connaitriez-vous un autre outils (à part BC7...)
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6
trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de
vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà
présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL.
Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien...
Et 2ème question, si ce n'en est pas, comment faire ?
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6.
Connaitriez-vous un autre outils (à part BC7...)
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien... Et 2ème question, si ce n'en est pas, comment faire ? Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6. Connaitriez-vous un autre outils (à part BC7...)
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien... Et 2ème question, si ce n'en est pas, comment faire ? Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6. Connaitriez-vous un autre outils (à part BC7...)
Merci pour le lien ! c'est exactement notre cas de "Dangling Pointer" !! Donc ouf, pas de pb dans notre code de ce coté là.
David Brabant wrote:
"amerio" <amerio@hotmail.com> wrote
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5,
BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à
l'intérieur du source de vector et list. Je sais ce qu'est un dangling
pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il
s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question :
sont-ce bien là des fausses alertes ? ou bien...
Et 2ème question, si ce n'en est pas, comment faire ?
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable
par BC6. Connaitriez-vous un autre outils (à part BC7...)
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien... Et 2ème question, si ce n'en est pas, comment faire ? Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6. Connaitriez-vous un autre outils (à part BC7...)
Merci pour le lien ! c'est exactement notre cas de "Dangling Pointer" !! Donc ouf, pas de pb dans notre code de ce coté là.
amerio
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien...
A ma connaissance, il n'y a pas de fuites de mémoire dans vector ou string de vc6 avec le SP5. Ceci dit, si tu stockes des pointeurs vers de la mémoire allouée dynamiquement dans tes containers, c'est à toi de libérer la mémoire en question. En ce qui concerne les "dangling pointers", il y en a peut-être dans l'implémentation interne de la STL, mais tant qu'ils ne sont pas déréférencés par le code de la STL et que tu n'y a pas accès, tu ne dvrais pas t'en soucier.
Et 2ème question, si ce n'en est pas, comment faire ? Ce sont des pointeurs accessibles depuis le code utilsiateur? Si non,
ce n'est pas ton problème.
(cf reponse de D.Brabant) Il s'agit bien de dangling pointer, mais ils ne sont pas déréférencés, donc aucun soucis.
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6. Un "patch mémoire" ? Tu veux dire une fuite? Comment sais-tu que tu as
une fuite (quels symptomes) si BC ne la trouve pas?
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre code. Par contre, quelque part, un bout de code écrit par dessus un autre objet. Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun (mais jamais au même endroit, donc on arrive pas à identifier le coupable, et ca ressemble plus à un symptome qu'a la vraie cause), et parfois, ca écrit au beau milieu d'un objet, donc sans faire d'exeption sur le coup, on ne s'en rend compte qu'au moment du plantage, bcp plus tard) Et BC6 ne voit rien.
Cela fait maintenant plusieurs semaines qu'on cherche, et on envisage d'aller élever des moutons... Donc, a vot' bon coueur pour les idées...
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5,
BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à
l'intérieur du source de vector et list. Je sais ce qu'est un dangling
pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il
s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question :
sont-ce bien là des fausses alertes ? ou bien...
A ma connaissance, il n'y a pas de fuites de mémoire dans vector ou
string de vc6 avec le SP5. Ceci dit, si tu stockes des pointeurs vers
de la mémoire allouée dynamiquement dans tes containers, c'est à toi
de libérer la mémoire en question.
En ce qui concerne les "dangling pointers", il y en a peut-être dans
l'implémentation interne de la STL, mais tant qu'ils ne sont pas
déréférencés par le code de la STL et que tu n'y a pas accès, tu ne
dvrais pas t'en soucier.
Et 2ème question, si ce n'en est pas, comment faire ?
Ce sont des pointeurs accessibles depuis le code utilsiateur? Si non,
ce n'est pas ton problème.
(cf reponse de D.Brabant)
Il s'agit bien de dangling pointer, mais ils ne sont pas déréférencés, donc aucun soucis.
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable
par BC6.
Un "patch mémoire" ? Tu veux dire une fuite? Comment sais-tu que tu as
une fuite (quels symptomes) si BC ne la trouve pas?
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre code.
Par contre, quelque part, un bout de code écrit par dessus un autre objet.
Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun (mais jamais au
même endroit, donc on arrive pas à identifier le coupable, et ca ressemble plus à un
symptome qu'a la vraie cause), et parfois, ca écrit au beau milieu d'un objet, donc sans
faire d'exeption sur le coup, on ne s'en rend compte qu'au moment du plantage, bcp plus
tard)
Et BC6 ne voit rien.
Cela fait maintenant plusieurs semaines qu'on cherche, et on envisage d'aller élever des
moutons...
Donc, a vot' bon coueur pour les idées...
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien...
A ma connaissance, il n'y a pas de fuites de mémoire dans vector ou string de vc6 avec le SP5. Ceci dit, si tu stockes des pointeurs vers de la mémoire allouée dynamiquement dans tes containers, c'est à toi de libérer la mémoire en question. En ce qui concerne les "dangling pointers", il y en a peut-être dans l'implémentation interne de la STL, mais tant qu'ils ne sont pas déréférencés par le code de la STL et que tu n'y a pas accès, tu ne dvrais pas t'en soucier.
Et 2ème question, si ce n'en est pas, comment faire ? Ce sont des pointeurs accessibles depuis le code utilsiateur? Si non,
ce n'est pas ton problème.
(cf reponse de D.Brabant) Il s'agit bien de dangling pointer, mais ils ne sont pas déréférencés, donc aucun soucis.
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6. Un "patch mémoire" ? Tu veux dire une fuite? Comment sais-tu que tu as
une fuite (quels symptomes) si BC ne la trouve pas?
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre code. Par contre, quelque part, un bout de code écrit par dessus un autre objet. Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun (mais jamais au même endroit, donc on arrive pas à identifier le coupable, et ca ressemble plus à un symptome qu'a la vraie cause), et parfois, ca écrit au beau milieu d'un objet, donc sans faire d'exeption sur le coup, on ne s'en rend compte qu'au moment du plantage, bcp plus tard) Et BC6 ne voit rien.
Cela fait maintenant plusieurs semaines qu'on cherche, et on envisage d'aller élever des moutons... Donc, a vot' bon coueur pour les idées...
Loïc Joly
amerio wrote:
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien...
A ma connaissance, il n'y a pas de fuites de mémoire dans vector ou string de vc6 avec le SP5. Ceci dit, si tu stockes des pointeurs vers de la mémoire allouée dynamiquement dans tes containers, c'est à toi de libérer la mémoire en question. En ce qui concerne les "dangling pointers", il y en a peut-être dans l'implémentation interne de la STL, mais tant qu'ils ne sont pas déréférencés par le code de la STL et que tu n'y a pas accès, tu ne dvrais pas t'en soucier.
Et 2ème question, si ce n'en est pas, comment faire ?
Ce sont des pointeurs accessibles depuis le code utilsiateur? Si non, ce n'est pas ton problème.
(cf reponse de D.Brabant) Il s'agit bien de dangling pointer, mais ils ne sont pas déréférencés, donc aucun soucis.
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6.
Un "patch mémoire" ? Tu veux dire une fuite? Comment sais-tu que tu as une fuite (quels symptomes) si BC ne la trouve pas?
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre code. Par contre, quelque part, un bout de code écrit par dessus un autre objet. Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun (mais jamais au même endroit, donc on arrive pas à identifier le coupable, et ca ressemble plus à un symptome qu'a la vraie cause), et parfois, ca écrit au beau milieu d'un objet, donc sans faire d'exeption sur le coup, on ne s'en rend compte qu'au moment du plantage, bcp plus tard)
J'avais lu une technique dans un C/C++ user journal, qui peut peut-être s'appliquer dans ce cas :
Les OS fournissent en général (et windows le fait) des fonctions qui permettent de mettre un bout de mémoire en lecture seule. Donc, ton objet qui est écrasé, tu le protèges sauf dans ses setter ou fcts membre non const, et avec un peu de chance, tu verras une belle erreur dans le code qui écrase, et non plus dans le code écrasé.
Autrement, une des meilleures méthodes que je connais pour ça est la revue de code.
-- Loïc
amerio wrote:
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5,
BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à
l'intérieur du source de vector et list. Je sais ce qu'est un dangling
pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il
s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question :
sont-ce bien là des fausses alertes ? ou bien...
A ma connaissance, il n'y a pas de fuites de mémoire dans vector ou
string de vc6 avec le SP5. Ceci dit, si tu stockes des pointeurs vers
de la mémoire allouée dynamiquement dans tes containers, c'est à toi
de libérer la mémoire en question.
En ce qui concerne les "dangling pointers", il y en a peut-être dans
l'implémentation interne de la STL, mais tant qu'ils ne sont pas
déréférencés par le code de la STL et que tu n'y a pas accès, tu ne
dvrais pas t'en soucier.
Et 2ème question, si ce n'en est pas, comment faire ?
Ce sont des pointeurs accessibles depuis le code utilsiateur? Si non,
ce n'est pas ton problème.
(cf reponse de D.Brabant)
Il s'agit bien de dangling pointer, mais ils ne sont pas déréférencés, donc aucun soucis.
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable
par BC6.
Un "patch mémoire" ? Tu veux dire une fuite? Comment sais-tu que tu as
une fuite (quels symptomes) si BC ne la trouve pas?
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre code.
Par contre, quelque part, un bout de code écrit par dessus un autre objet.
Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun (mais jamais au
même endroit, donc on arrive pas à identifier le coupable, et ca ressemble plus à un
symptome qu'a la vraie cause), et parfois, ca écrit au beau milieu d'un objet, donc sans
faire d'exeption sur le coup, on ne s'en rend compte qu'au moment du plantage, bcp plus
tard)
J'avais lu une technique dans un C/C++ user journal, qui peut peut-être
s'appliquer dans ce cas :
Les OS fournissent en général (et windows le fait) des fonctions qui
permettent de mettre un bout de mémoire en lecture seule. Donc, ton
objet qui est écrasé, tu le protèges sauf dans ses setter ou fcts membre
non const, et avec un peu de chance, tu verras une belle erreur dans le
code qui écrase, et non plus dans le code écrasé.
Autrement, une des meilleures méthodes que je connais pour ça est la
revue de code.
Dans un gros projet ou on utilise std::vector et std::list, avec VC6+sp5, BoundsChecker 6 trouve une quantité assez importante de "dangling pointer" à l'intérieur du source de vector et list. Je sais ce qu'est un dangling pointer (et ses risques), mais jusquà présent, j'ai toujours considéré qu'il s'agissait de fausses alertes de BC6 dans la STL. Donc, 1ère question : sont-ce bien là des fausses alertes ? ou bien...
A ma connaissance, il n'y a pas de fuites de mémoire dans vector ou string de vc6 avec le SP5. Ceci dit, si tu stockes des pointeurs vers de la mémoire allouée dynamiquement dans tes containers, c'est à toi de libérer la mémoire en question. En ce qui concerne les "dangling pointers", il y en a peut-être dans l'implémentation interne de la STL, mais tant qu'ils ne sont pas déréférencés par le code de la STL et que tu n'y a pas accès, tu ne dvrais pas t'en soucier.
Et 2ème question, si ce n'en est pas, comment faire ?
Ce sont des pointeurs accessibles depuis le code utilsiateur? Si non, ce n'est pas ton problème.
(cf reponse de D.Brabant) Il s'agit bien de dangling pointer, mais ils ne sont pas déréférencés, donc aucun soucis.
Question subsidiaire : on a un (gros) patch mémoire qui traine, introuvable par BC6.
Un "patch mémoire" ? Tu veux dire une fuite? Comment sais-tu que tu as une fuite (quels symptomes) si BC ne la trouve pas?
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre code. Par contre, quelque part, un bout de code écrit par dessus un autre objet. Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun (mais jamais au même endroit, donc on arrive pas à identifier le coupable, et ca ressemble plus à un symptome qu'a la vraie cause), et parfois, ca écrit au beau milieu d'un objet, donc sans faire d'exeption sur le coup, on ne s'en rend compte qu'au moment du plantage, bcp plus tard)
J'avais lu une technique dans un C/C++ user journal, qui peut peut-être s'appliquer dans ce cas :
Les OS fournissent en général (et windows le fait) des fonctions qui permettent de mettre un bout de mémoire en lecture seule. Donc, ton objet qui est écrasé, tu le protèges sauf dans ses setter ou fcts membre non const, et avec un peu de chance, tu verras une belle erreur dans le code qui écrase, et non plus dans le code écrasé.
Autrement, une des meilleures méthodes que je connais pour ça est la revue de code.
-- Loïc
amerio
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre code. Par contre, quelque part, un bout de code écrit par dessus un autre objet. Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun (mais jamais au même endroit, donc on arrive pas à identifier le coupable, et ca ressemble plus à un symptome qu'a la vraie cause), et parfois, ca écrit au beau milieu d'un objet, donc sans faire d'exeption sur le coup, on ne s'en rend compte qu'au moment du plantage, bcp plus tard)
J'avais lu une technique dans un C/C++ user journal, qui peut peut-être s'appliquer dans ce cas :
Les OS fournissent en général (et windows le fait) des fonctions qui permettent de mettre un bout de mémoire en lecture seule. Donc, ton objet qui est écrasé, tu le protèges sauf dans ses setter ou fcts membre non const, et avec un peu de chance, tu verras une belle erreur dans le code qui écrase, et non plus dans le code écrasé.
Tu aurais des indic plus precises là dessus ?
Autrement, une des meilleures méthodes que je connais pour ça est la revue de code. Oui, le pb est que l'on est (presque) sur que ce pb vient d'une lib tierce partie.
On voudrait pouvoir confirmer, pour leur taper dessus ;-).
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre
code.
Par contre, quelque part, un bout de code écrit par dessus un autre objet.
Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun
(mais jamais au même endroit, donc on arrive pas à identifier le coupable,
et ca ressemble plus à un symptome qu'a la vraie cause), et parfois, ca
écrit au beau milieu d'un objet, donc sans faire d'exeption sur le coup, on
ne s'en rend compte qu'au moment du plantage, bcp plus tard)
J'avais lu une technique dans un C/C++ user journal, qui peut peut-être
s'appliquer dans ce cas :
Les OS fournissent en général (et windows le fait) des fonctions qui
permettent de mettre un bout de mémoire en lecture seule. Donc, ton
objet qui est écrasé, tu le protèges sauf dans ses setter ou fcts membre
non const, et avec un peu de chance, tu verras une belle erreur dans le
code qui écrase, et non plus dans le code écrasé.
Tu aurais des indic plus precises là dessus ?
Autrement, une des meilleures méthodes que je connais pour ça est la
revue de code.
Oui, le pb est que l'on est (presque) sur que ce pb vient d'une lib tierce partie.
On voudrait pouvoir confirmer, pour leur taper dessus ;-).
Un patch, pas un leak (ou fuite). On n'a aucune fuite de mémoire dans notre code. Par contre, quelque part, un bout de code écrit par dessus un autre objet. Parfois, ca écrase la pile d'appel, parfois ca se traduit par un overrun (mais jamais au même endroit, donc on arrive pas à identifier le coupable, et ca ressemble plus à un symptome qu'a la vraie cause), et parfois, ca écrit au beau milieu d'un objet, donc sans faire d'exeption sur le coup, on ne s'en rend compte qu'au moment du plantage, bcp plus tard)
J'avais lu une technique dans un C/C++ user journal, qui peut peut-être s'appliquer dans ce cas :
Les OS fournissent en général (et windows le fait) des fonctions qui permettent de mettre un bout de mémoire en lecture seule. Donc, ton objet qui est écrasé, tu le protèges sauf dans ses setter ou fcts membre non const, et avec un peu de chance, tu verras une belle erreur dans le code qui écrase, et non plus dans le code écrasé.
Tu aurais des indic plus precises là dessus ?
Autrement, une des meilleures méthodes que je connais pour ça est la revue de code. Oui, le pb est que l'on est (presque) sur que ce pb vient d'une lib tierce partie.
On voudrait pouvoir confirmer, pour leur taper dessus ;-).
Merci pour le lien ! c'est exactement notre cas de "Dangling Pointer" !!
j'ai suivi la descution de prés, mais je suis un peu perdu. Finalement c'est une erreur au niveau stl ou pas; car si j'ai bien compris dans lien, ils disentau debut que BoundsChecker n'a pas tort de reporter cette erreur, et que le le prog de stl n'est faux. A la fin il disent c'est plus prudent de corriger l'erreur.J'avoue que je suis un peu perdu. merci d'avance.
Donc ouf, pas de pb dans notre code de ce coté là. Donc c'est au niveau stl?
Merci pour le lien ! c'est exactement notre cas de "Dangling Pointer" !!
j'ai suivi la descution de prés, mais je suis un peu perdu. Finalement
c'est une erreur au niveau stl ou pas;
car si j'ai bien compris dans lien, ils disentau debut que
BoundsChecker n'a pas tort de reporter cette erreur, et que le le prog
de stl n'est faux. A la fin il disent c'est plus prudent de corriger
l'erreur.J'avoue que je suis un peu perdu.
merci d'avance.
Donc ouf, pas de pb dans notre code de ce coté là.
Donc c'est au niveau stl?
Merci pour le lien ! c'est exactement notre cas de "Dangling Pointer" !!
j'ai suivi la descution de prés, mais je suis un peu perdu. Finalement c'est une erreur au niveau stl ou pas; car si j'ai bien compris dans lien, ils disentau debut que BoundsChecker n'a pas tort de reporter cette erreur, et que le le prog de stl n'est faux. A la fin il disent c'est plus prudent de corriger l'erreur.J'avoue que je suis un peu perdu. merci d'avance.
Donc ouf, pas de pb dans notre code de ce coté là. Donc c'est au niveau stl?
