Discussion :

[Klaim]

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

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?

[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.

[Klaim]

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?

[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.

[Klaim]

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

[Iradrille]

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.

[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?

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

[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).

[Klaim]

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..........
Mais JolyLoic l'utilise aussi sans probleme.

[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.

[Médinoc]

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 C++ :

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

[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.

[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

[Médinoc]

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.

[Klaim]

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

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?

[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".

[Klaim]

Je n'ai pas encore verifie (trop de boulot, E3 a tue mon sommeil , 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.

[Médinoc]

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