Problèmes pour debuguer sur windows 64 bits du code 32 bits

Version imprimable

08/06/2013, 12h24
Klaim

Problèmes pour debuguer sur windows 64 bits du code 32 bits

EDIT : Cette discussion est un "spin off"de http://www.developpez.net/forums/d13...r/#post7337145

Citation:

Envoyé par Médinoc

Sinon, ça peut aussi être le debugger qui déconne si tu es sous un Windows 64 bits et que ton programme est en 32 bits.

En quoi ca peut poser un probleme? Ou tu parles d'un autre debugger que celui de VS?
08/06/2013, 18h16
Médinoc

En quoi ça peut poser un problème: C'est simple: Le debugger de Visual affiche n'importe quoi et suit mal l'exécution du code en pas à pas, même quand le code 32 bits en question est compilé en Debug. J'ignore pourquoi, mais j'ai fait l'expérience de ce problème.
08/06/2013, 19h22
Klaim

8O
Ca me surprends beaucoup parceque je suis sous Win 7 64bit depuis plusieurs annees et j'ai debugge des tas de programmes 32 et 64 bit dont la plupart hautement multithread mais je n'ai jamais vu le comportement dont tu parles. Ou alors ca doit etre une categorie de cas precis?
09/06/2013, 10h17
Médinoc

En tout cas, j'ai vu ça à mon bureau (Windows 7 64 bits également), sur des programmes C ou C++ 32 bits sous au moins une version de Visual (2005, 2008 ou 2010).
Et c'est reproductible, ce n'est pas ponctuel.

↓Il faudra que je vois ça en semaine.
09/06/2013, 12h06
Klaim

Citation:

Envoyé par Médinoc

En tout cas, j'ai vu ça à mon bureau (Windows 7 64 bits également), sur des programmes C ou C++ 32 bits sous au moins une version de Visual (2005, 2008 ou 2010).
Et c'est reproductible, ce n'est pas ponctuel.

Si tu as encore le code je veux bien re-tester sur VS2010 et VS2012 (dernieres updates pour les deux par contre).
09/06/2013, 13h53
Iradrille

Citation:

Envoyé par Médinoc

En quoi ça peut poser un problème: C'est simple: Le debugger de Visual affiche n'importe quoi et suit mal l'exécution du code en pas à pas, même quand le code 32 bits en question est compilé en Debug. J'ignore pourquoi, mais j'ai fait l'expérience de ce problème.

Je confirme, et c'est beaucoup plus fréquent avec des programmes multithreads.
Pas de code reproduisant le problème sous la main par contre.
09/06/2013, 14h10
Klaim

Bon ben perso je vois pas ce probleme. J'ai bosse deja un an sur un moteur de jeu multithread sans voir ca, et c'est bien du 32bit. Vous etes sur que vous vous etes pas trompe d'interpretation de ce que faisais le debugger?
09/06/2013, 14h18
Iradrille

1 pièce(s) jointe(s)

Non, ya vraiment des-fois ou le débogueur galère, j'ai retrouvé 2 screens qui montrent le problème (VS 2012 + CTP November)
Le code à énormément changé entre temps (et n'est pas un exemple minimal, je le mettrais pas ici)
09/06/2013, 16h25
JolyLoic

Ton screenshot ne montre pas grand'chose, tant qu'on n'en sait pas plus sur ce qu'il y a autour (code, ce que font les différentes fonctions appelées, quels threads sont actifs...). Ton this a changé, ce qui peut être lié a plein de choses sans qu'il y ait le moindre problème dans le débogueur.

J'ai pour ma part pas mal bossé sur ce genre d'environnement, sans avoir de soucis (tant que je déboguais la version debug et non release, bien entendu).
09/06/2013, 18h26
Klaim

Citation:

Envoyé par Iradrille

Non, ya vraiment des-fois ou le débogueur galère, j'ai retrouvé 2 screens qui montrent le problème (VS 2012 + CTP November)
Le code à énormément changé entre temps (et n'est pas un exemple minimal, je le mettrais pas ici)

Note que le CTP n est pas une version stable..........:aie:
Mais JolyLoic l'utilise aussi sans probleme.
09/06/2013, 18h54
Bousk

La seule fois où j'ai eu un problème de ce genre, c'était un dépassement mémoire qui me plantait pas en Debug parce que j'accédais à un morceau aussi m'appartenant.

J'ai pu reproduire le bug sous Visual Studio 2008, exécuté en administrateur sous Window 7 64 bits. Je possède cette fonction, appelée depuis une TimerProc (dont j'ai étendu le délai à dix secondes pour m'assurer que le problème ne vient pas d'un double-appel) et avec un breakpoint sur la première ligne:
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 32 33 34 35 36 //Create a ShellWindows object, and call enumProc on its contents. EXTERN_C HRESULT EnumShellWindows(INT_PTR userData, SHLWNDENUMPROC enumProc) { if(enumProc==NULL) return E_POINTER; HRESULT hr; IShellWindowsPtr spWindows = NULL; hr = CoCreateInstance(CLSID_ShellWindows, NULL, CLSCTX_INPROC_SERVER|CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(&spWindows)); if(FAILED(hr)) { switch(hr) { case REGDB_E_CLASSNOTREG: //If this occurs, it's very unexpected, but identifiable. return hr; default: return E_UNEXPECTED; } } assert(spWindows!=NULL); hr = S_OK; IDispatchPtr spDispWindow=NULL; for(UINT index=0 ; hr==S_OK && IShellWindows_Item_int(spWindows, index, &spDispWindow)==S_OK ; index++) { HRESULT hrProc = enumProc(userData, spDispWindow); if(FAILED(hrProc)) hr = E_UNEXPECTED; if(hrProc==S_FALSE) hr = S_FALSE; spDispWindow.Release(); } return hr; }
J'ai vérifié que sa déclaration est identique à sa définition, que la TimerProc possède un prototype correct (elle est bien déclarée __stdcall, aucun cast sur les pointeurs de fonction), etc. Le code marche parfaitement hors du debugger, en Debug comme en Release, en 64 bits comme en 32 bits.
En 64 bits, le debugger marche normalement: ça breake sur le if, je fais F11 et ça passe à la ligne du CoCreateInstance().
En 32 bits, ça breake sur le if, mais quand je fais F11, ça re-breake sur la même ligne immédiatement après; si je refais F11, j'ai une Access Violation dans ntdll.dll dans le processus.
Le programme n'a qu'un seul thread, l'erreur ne peut donc pas venir d'un thread parallèle.

Edit: En fait, quand je fais F11 la première fois sur le if(), il semblerait que j'ai la "first-chance exception" de l'Access Violation. En lecture de la valeur d'un paramètre.:cfou:
Je rappelle que le même code, en Debug comme en Release, marche parfaitement hors du debugger. Oh, et Visual me dit seulement "Access Violation" au lieu d'un truc du genre "Access Violation reading 0x12345678", donc pas moyen de savoir grand-chose...

10/06/2013, 12h06
Klaim

Ca m'a l'air bien etrange, mais cela dis si tu debug sous VS2008 je me dis que ca pourrait etre lie (et aussi peut etre le Extern C...) parcequ'il est pas franchement fait pour marcher sur du 64bit.

C'est marrant tout ca me rapelle bien des trucs mais a chaque fois c'etait des problemes dans mon code. Aussi, je ne touche jamais au genre de code que tu montre ici parceque c'est trop specifique a windows, du coup il se peut que ce soit lie aussi.
10/06/2013, 12h12
Klaim

J'ai fais un peu de recherche, je trouve des docs dans ce genre qui indiquent que peut etre tu as essaye de debugger avec les debugging tools 64bit alors qu'il faut les 32 bits (je comprends pas bien ce que ca veut dire cela dis): http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
10/06/2013, 16h15
Médinoc

1 pièce(s) jointe(s)

J'ai pu reproduire sous Visual 2010, et ajouté un nouveau test: Si j'exécute le code dans le debugger sans mettre un breakpoint, ça marche nickel.
Si je mets un breakpoint au début de ma timerproc ou d'une fonction appelée par elle, ça marche si je refais F5 (Go) immédiatement, et ça excepte si je fais F10 (Step over) ou F11 (step into) à la place.

En 64 bits, ça ne plante pas.
Par contre, la présence d'un breakpoint dans la fonction mais ça fait échouer un appel à CoCreateInstance() avec la valeur de retour bizarre 0x804F4C45, qui est inconnue au bataillion sous Windows.
Et sans breakpoint, ça marche nickel.

J'ai joint le projet dans un ZIP. Le timer est toujours réglé à dix secondes (en usage normal, je mets une seconde à la place).

Edit: Et apparemment, je ne suis pas le seul à avoir ce problème.
10/06/2013, 21h02
Klaim

Je crois que ca fais plus de 10 ans que j'avais pas vu du code comme ca :aie:

Je viens d'ouvrir le projet sous vs2012U2 histoire de voir.
Je suis pas sur de comprendre ou mettre le breakpoint, tu peux me donner un endroit precis ou tu as le probleme, voir si j'arrive a le reproduire?
11/06/2013, 07h02
Médinoc

Tu vois la fonction EnumShellWindows() que j'ai postée? Tu mets un breakpoint sur sa première ligne if(enumProc==NULL), et ça excepte dessus quand tu steppes avec F10 ou F11.

D'un autre côté, les problèmes ont disparu aussi bien en 32 qu'en 64 quand j'ai suivi le conseil sur StackOverflow et décoché l'option "Enable RPC debugging".
11/06/2013, 15h54
Klaim

Je n'ai pas encore verifie (trop de boulot, E3 a tue mon sommeil :aie:, etc.) mais j'etais en train de me dire qu'il se peut que CMake force la bonne config des le depart et que du coup je ne peut pas voir le probleme dans mes projets actuels. A verifier.
11/06/2013, 16h06
Médinoc

Ce n'est pas dans le projet, mais dans Visual lui-même.