Discussion :

[inertia]

Bonjour, je programme sous visual studio 2003 une application concernant le son. Grossi�rement il s'agit d'une interface graphique en .net(Framework .net) qui fait appel � des dll.

Dans l'une des DLL appel�e, il se produit une erreur curieuse uniquement en release, �a passe en debug.

Je re�ois une boite de dialogue qui m'explique qu'il s'est produit une NullReferenceException.

J'active d'abord toutes les exception dans le d�buggeur visual studio mais rien � faire, je n'arrive pas � reproduire l'erreur en debug.

A l'aide de MessageBox j'identifie la ligne de code sur laquelle mon programme plante, en RELEASE. Il s'agit d'une b�te allocation � l'aide de new :

m_pRawBuffers = new AVRawDataBuffer[uNumBuffers];

uNumBuffers vaut 1 (pass� en argument)

Je ne comprend pas cette erreur, je n'ai m�me pas le temps de v�rifier la validit� mon pointeur m_pRawBuffers que le programme crash.

Une id�e ? je cherche depuis plusieurs jours.

Merci

[inertia]

J'ai tent� de catcher l'appel du new, le bloc catch est bien appel�. Il s'agit donc bien d'une erreur de l'operateur new. Seulement je ne comprend pas pourquoi. Mon PC dispose encore de 400-500mo de RAM avant chargement du fichier son.

Si on �carte le manque de m�moire, quelle cause peuvent faire planter new ?

[M�dinoc]

�a peut �tre le constructeur de AVRawDataBuffer qui lance une exception, si l'erreur retourn�e est autre chose que std::bad_alloc...
Sinon, faire du printf-debugging pour v�rivier que uNumBuffers vaut bien 1 et non une valeur bizarro�de genre 0xCCCCCCCC...

[inertia]

AVRawBuffer est une structure toute b�te :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
 
typedef struct AVRawDataBuffer
	{
		void				* pBuffer;
		struct AVRawDataBuffer	* pNextBuffer;
		struct AVRawDataBuffer	* pPrevBuffer;
 
		//Données pour utilisations diverses
		DWORD	dwFlag1;
		DWORD	dwFlag2;
	}AVRawDataBuffer;

uNumBuffer vaut bien 1, pas de soucis.

De plus, le programme plante sur des new mais pas syst�matiquement sur celui l�. je penche pour une corruption de la m�moire, je pense qu'il se produit quelque chose genre un d�passement d'indice de tableau. Le probl�me ne doit pas se trouver l� mais bien avant.

Quel outils puis je utiliser pour v�rifier l'utilisation m�moire lors de l'�x�cution en release ? Je sais que de tel outils existent mais je n'en connais aucun.

Merci

[M�dinoc]

Si c'est un d�passement de tableau, tu peux refaire la m�me chose en Debug et r�gler appeler une fonction de debug pour dire "v�rification absolument syst�matique du tas". Cela rendra l'application encore plus lente que d'habitude en debug, mais les chances que la CRT d�tecte le "mauvais" buffer seront plus grandes.

[koala01]

Salut,

As-tu d�j� conscience du fait que cette structure est, typiquement, �crite en C

En C++, ce serait, tout simplement (si le nom du type que tu veux utiliser pour cette structure est AVRawDataBuffer)

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
struct AVRawDataBuffer
{
    void * pBuffer;
    AVRawDataBuffer * pNextBuffer;
    AVRawDataBuffer* pPrevBuffer;
 
		//Données pour utilisations diverses
    DWORD dwFlag1;
    DWORD dwFlag2;
};

(il serait d'ailleurs peut �tre utile d'envisager une structure template, pour �viter cet horrible void * pbuffer )

Cela ne change rien au probl�me, mais c'est plus dans une optique C++

[inertia]

Si c'est un d�passement de tableau, tu peux refaire la m�me chose en Debug et r�gler appeler une fonction de debug pour dire "v�rification absolument syst�matique du tas". Cela rendra l'application encore plus lente que d'habitude en debug, mais les chances que la CRT d�tecte le "mauvais" buffer seront plus grandes.

Je ne comprend pas trop, on peut d�finir �a quelque part dans le debugger ? J'ai d�j� activ� toutes les exceptions avec "break into the debugger" mais sans succ�s ...

[inertia]

Ah ok, tu parles surement d'appeler une fonction dans le try catch.

Le probl�me c'est que le plantage est al�atoire.

[M�dinoc]

Non, c'est une fonction qu'on appelle depuis le code.
Un truc du genre _CrtSetDebugMode(), mais pas forc�ment celle-ci.
Edit: _CrtSetDbgFlag() avec le flag _CRTDBG_CHECK_ALWAYS_DF. Voir le second exemple de code, juste avant la section Requirements.

[inertia]

Malheureusement pour moi, �a ne change rien.

[inertia]

Probl�me r�solut, il s'agissait d'un alignement diff�rent par d�faut entre mes projets.