NullReferenceException en release

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

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 ?

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

AVRawBuffer est une structure toute bête :

Code:

---

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

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.

Salut,

As-tu déjà conscience du fait que cette structure est, typiquement, écrite en C :question:

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

Code:

---

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

Citation:

---

Envoyé par 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.

---

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

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

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

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.

Malheureusement pour moi, ça ne change rien. :evilred:

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