Pourquoi pourrait déclencher un point d'arrêt lorsque je renvoie TRUE à partir de mon OnCopyData?

Question

J'utilise Visual Studio pour déboguer une application ATL.

Lorsque je fais un pas sur return TRUE dans ce code, l'erreur se produit:

BOOL CMainFrame::OnCopyData(CWnd* pWnd, COPYDATASTRUCT* pCopyDataStruct) { 

    // Code snipped from here - maybe this causes stack/heap corruption? 

    // I have a breakpoint here, if I step over (F10), AFX trace message 
    // is shown (as below) 
    return TRUE; 

} 

C'est la boîte de message qui est affiché:

Windows a déclenché un point d'arrêt dans foobar.exe.

Cela peut être dû à une corruption du tas , ce qui indique un bogue dans foobar.exe ou l'une des DLL qu'il a chargé.

Cela peut également être due à l'utilisateur en appuyant sur F12 tandis que phonejournal.exe a focus. La fenêtre de sortie peut contenir plusieurs informations de diagnostic .

Le message est un peu vague, et je me demande quels outils je peux utiliser pour obtenir plus d'informations. Les pauses débogueur sur l'appel à AtlTraceVU dans atltrace.h:

inline void __cdecl CTrace::TraceV(const char *pszFileName, int nLine, 
    DWORD_PTR dwCategory, UINT nLevel, LPCWSTR pszFmt, va_list args) const 
{ 
    AtlTraceVU(m_dwModule, pszFileName, nLine, dwCategory, nLevel, pszFmt, args); 
} 

Answer 1

Le Application Verifier de Microsoft peut aider avec ceci. Si l'application a une corruption de tas, cet utilitaire peut provoquer l'exception à se produire lorsque l'erreur se produit. Cependant, il peut utiliser beaucoup de mémoire en cours d'exécution, car il peut produire de grands changements dans les schémas d'allocation de mémoire.

Le code suivant évidemment imparfait donne une démonstration simple:

char *pc = malloc(4); 
memcpy(pc, "abcdabcd", 9); 
free(pc); 

Quand je courais cela sans vérification de l'application, il a couru à la fin sans erreur évidente. Avec le vérificateur d'application, cependant, il a provoqué une exception (0x80000003). Application Verifier a forcé l'allocation à être à la fin d'un segment (par exemple, 0x1e9eff8). Le memcpy a entraîné une écriture dans le segment suivant, ce qui a entraîné l'exception au cours de l'appel memcpy. Si l'écrasement est moindre dans cet exemple simple, la coupure ne se produit pas avant l'appel free, mais c'est toujours mieux qu'aucune exception. C'est un utilitaire plutôt cool.

Answer 2

Votre mémoire (peut-être votre pile) est endommagé par un pointeur rétif quelque part ailleurs dans le code.