Migration vers VS2010 crée un heap corruption

Version imprimable

04/02/2011, 20h45
djuju

Migration vers VS2010 crée un heap corruption

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
05/02/2011, 14h34
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. :aie:

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. :calim2:

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).
08/02/2011, 23h07
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 :calim2:

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
08/02/2011, 23h41
bacelar

Citation:

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.

Citation:

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.

Citation:

Envoyé par bacelar

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:

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()

10/02/2011, 20h18
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 ?
11/02/2011, 00h16
bacelar

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

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

Mais ça pue l'utilisation de globales, et les globales, c'est MAL. :aie:
15/02/2011, 19h31
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 :cry:
Il va vraiment falloir que je prenne du temps sur ce problème si je ne veux pas induire de bugs.

Encore merci :ccool: