Discussion :

[pierre_h]

Salut,

je suis victime d'un plantage (StackOverflow) au moment de faire appel la méthode InvokeHelper pour exécution d'une des fonctions d'un ActiveX.

Methode appelée : (généré par le wizard)

Code :

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

1
2
3
4
5
6
7
8
9
10
 
short MonOCX::MaFonction(LPCTSTR DataStr)
{
	short result;
	static BYTE parms[] =
		VTS_BSTR;
	InvokeHelper(0x24, DISPATCH_METHOD, VT_I2, (void*)&result, parms,
		DataStr);
	return result;
}

L'ID de la méthode (0x24) est bon, il se réfère à la bonne fonction de l'ActiveX.

En entrée on a une CString (DataStr), seul paramètre, défini dans le tableau de params par VTS_BSTR.

Le type de la valeur de retour (short) est bien défini : VT_I2.


Hors, l'application crash ligne 252 dans oledisp2.cpp au moment d'un SysAllocString()... Mais pourquoi ? Les paramètres sont pourtant correct.

OleDisp2.cpp :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#if !defined(_UNICODE) && !defined(OLE2ANSI)
			case VT_BSTRA:
				{
					LPCSTR lpsz = va_arg(argList, LPSTR);
					pArg->bstrVal = ::SysAllocString(T2COLE(lpsz));
					if (lpsz != NULL && pArg->bstrVal == NULL)
						AfxThrowMemoryException();
					pArg->vt = VT_BSTR;
				}
				break;
#endif

On peut voir que la chaine subit une conversion (vers du wild vraissemblablement) via la macro A2W (ATLCONV.H).

Le fait que le crash survienne dans les fichiers MFC, ne laisse guère de marge de manœuvre...

Bref, je sèche quant à l'origine de ce crash...

Merci d'avance.

Pierre.

NB:
Config : VC6

[white_tentacle]

Y a-t-il récursivité quelque part ?

A2W alloue sur la pile, en cas d'appels récursifs, c'est dramatique et provoque des stack overflows.

Mieux vaut utiliser CA2W.

[pierre_h]

Merci pour ta réactivité White_tentacle.

Y a-t-il récursivité quelque part ?

A2W alloue sur la pile, en cas d'appels récursifs, c'est dramatique et provoque des stack overflows.

Pas de recursivité à ma connaissance, juste un appel à m_MonOcx.MaFonction("szStr"); puis le crash dans OleDisp2.cpp.

Mieux vaut utiliser CA2W.

Je ne peux pas changer ça...A2W est appelée dans OleDisp2.cpp via T2COLE.

[Médinoc]

Et surtout, CA2W n'est pas disponible sous VC6.
Pour info, VC8 utilise directement une CStringW, donc je pense que VC6 est bien le noyau du problème.

Pour le contourner, je te propose de modifier ta fonction générée par le wizard pour faire la conversion unicode toi-même (de la façon qui te plaira, mais je conseille de créer/utiliser une classe spécifique) avant d'appeler InvokeHelper...
Et remplacer VTS_BSTR par VTS_WBSTR.

[pierre_h]

Merci medinoc pour ces précisions. Cette solution me plait.

Bon c'est testé et plus de crash. Bravo !

Un grand merci pour vos réponses et à Developpez.com car se sentir entouré de pros n'a pas de prix.

[pierre_h]

Encore une question :

Pourquoi ce plantage ?

Est-ce la macro A2W qui n'arrivait pas à convertir la chaine (approximativement 500 000 caractères) ?

SysAllocString qui n'arrivait pas allouer assez d'espace ?

Je sens que quelqu'un à la réponse...

[Médinoc]

Eh bien, vu que A2W utilise alloca pour stocker son buffer (et ne pas avoir à le désallouer manuellement), ça sent le débordement de pile.
CA2W n'a pas ce problème parce que c'est une classe C++, pas une macro que je soupçonne d'être utilisable en C.

[pierre_h]

Effectivement. D'ailleurs, selon MSDN : alloca génére une exception de type StackOverflow au cas où elle n'arrive pas à allouer l'espace nécessaire.

Donc pour résumer pour ceux qui auraient le même soucis :
Se débrouiller pour faire passer une chaine plus petite, ou faire la conversion vers l'unicode vous même en modifiant le type des paramètres passés à InvokeHelper (VTS_WBSTR au lieu de VTS_BSTR).

Encore merci.

Pierre.