Discussion :

[djuju]

Bonjour,

Je voudrais migrer une solution contenant plusieurs projets de VC++ 2005 a VC++ 2010.
J'ai convertie et recompilé la solution, mais lorsque je lance l'application, visual studio détecte un heap corruption avant même d'exécuter la première instruction de mon code.

Par contre, si je migre le code en VC++ 2008, je n'ai aucun bug (mais le bug revient si je re-migrer le code 2008 en 2010).

Quelles peuvent être les raisons de ce bug ?

Merci
dJu

[bacelar]

- le Runtime C fourni avec VS2010 peut-être plus performant pour la détection de problème de mémoire.
-> Révélation de bugs latents

- Mise en conformité de certains comportements des bibliothèques "standard" avec les normes.
-> Révélation de bugs latents dû à l'utilisation d'un comportement non standard

- Changement d'un comportement des bibliothèques "standard"
-> Révélation d'un code utilisant un comportement indéfini des bibliothèques "standard".

- Bugs dans les nouvelles bibliothèques
-> Révélation d'un bugs dans les bibliothèques, un petit rapport a M$ serait sympa si le bug est bien confirmé.

- etc...

- Le problème peut aussi être entre la chaise et le clavier.


En résumé, utilisez les outils de debugging contenu dans VS, le code des bibliothèques est fourni, je crois même avec la version Express.
Regardez le code qui plante, il ne va pas vous brûler les yeux.

Problèmes probables:
- utilisation "limite" des variables globales
- changement de la configuration du projet (les règles par défauts, ou action de l'outil de migration).

[djuju]

Bonjour et merci de votre résponse.

En fait, j'aimerais bien regarder le code qui plante, mais mon heap corruption se produit avant même d'atteindre la première instruction du code, ce qui le rend très délicat à débuguer

Je dois avoué que je ne sais plus trop par quel bout prendre ce problème.

Pour l'instant, je contourne le problème en compilant le code en VC9 depuis VC10.

dJu

[bacelar]

mais mon heap corruption se produit avant même d'atteindre la première instruction du code

J'en doute beaucoup.
N'oubliez pas que le code d"initialisation de vos variables globales et statiques est appelé avant même l'appel de votre main.

Le code d'initialisation de que le compilateur crée pour vous est du code C tout aussi visible dans la callstack que le votre.

Regardez le code qui plante, il ne va pas vous brûler les yeux.

J'insiste, le code de la C-runtime en Debug est truffé d'instruction de vérification pour vous aidez à voir les problèmes dans VOTRE code.

[djuju]

N'oubliez pas que le code d"initialisation de vos variables globales et statiques est appelé avant même l'appel de votre main.

Effectivement, je n'avais pas pensé à ça. Je vais cherché dans cette direction. Je n'ai pas beaucoup de variables globale, je vais essayé de mettre un breakpoint sur chacune.

Cependant, la call stack ne me permet pas d'atteindre les instruction de mon code (voir ci-dessous).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
msvcr100d.dll!_msize_dbg(void * pUserData, int nBlockUse)  Line 1516 + 0x30 bytes	C++
msvcr100d.dll!_dllonexit_nolock(int (void)* func, void (void)* * * pbegin, void (void)* * * pend)  Line 291 + 0xd bytes	C
msvcr100d.dll!__dllonexit(int (void)* func, void (void)* * * pbegin, void (void)* * * pend)  Line 269 + 0x11 bytes	C
ScannI.exe!_onexit(int (void)* func)  Line 110 + 0x18 bytes	C
ScannI.exe!atexit(void (void)* func)  Line 127 + 0x9 bytes	C
ScannI.exe!std::`dynamic initializer for '_Fac_tidy_reg''()  Line 49 + 0xf bytes	C++
[Managed to Native Transition]	
ScannI.exe!_initterm(void** pfbegin, void pfend) Line 132	C++
ScannI.exe!<CrtImplementationDetails>::LanguageSupport::InitializeNative() Line 376	C++
ScannI.exe!<CrtImplementationDetails>::LanguageSupport::_Initialize() Line 491	C++
ScannI.exe!<CrtImplementationDetails>::LanguageSupport::Initialize() Line 698	C++
ScannI.exe!?.cctor@@$$FYMXXZ() Line 749 + 0x9 bytes	C++
mscoreei.dll!603b55ab()
[Frames below may be incorrect and/or missing, no symbols loaded for mscoreei.dll]	
mscoree.dll!79007f16()
mscoree.dll!79004de3()
kernel32.dll!7c817067()
kernel32.dll!7c80e63b()
boost_regex-vc100-mt-gd-1_45.dll!00730079()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()
boost_regex-vc100-mt-gd-1_45.dll!006e0069()

[djuju]

Je viens de tester toutes mes variables globales et statique sans succès.
Par contre, j'ai peut être une piste. Les projets de cette solution sont utilisés dans une autre solution (migrable en VC10 sans problème). L'un de ces projets est une DLL, qui est utilisée en tant que dépendance de ma solution, donc sans passer par l'interface de la DLL, en utilisant directement les objets. Je me demande si cette galipette ne pourrait pas être à l'origine d'un problème de mémoire partagée.
Qu'en pensez vous ?

[bacelar]

Avec la stack, les recherches dans Google sont bien plus efficaces.

http://social.msdn.microsoft.com/for...7-97ae6badc4d7

Mais ça pue l'utilisation de globales, et les globales, c'est MAL.

[djuju]

Merci beaucoup de ton aide !

Tu as tout à fait raison: les globales c'est mal et ca pue ... Malheureusement ce code n,a pas toujours été écrit par de bons programmeurs... On doit vivre avec l'existant
Il va vraiment falloir que je prenne du temps sur ce problème si je ne veux pas induire de bugs.

Encore merci