Perché potrebbe _CrtSetBreakAlloc non causa un punto di interruzione?

Question

Sto utilizzando Visual CRT rilevamento della perdita di memoria di routine da <crtdbg.h>;quando l'ho chiamata _CrtDumpMemoryLeaks una allocazione viene segnalato in modo coerente su ogni invocazione del programma:

{133} normal block at 0x04F85628, 56 bytes long.
 Data: <                > B0 81 F8 04 B0 81 F8 04 B0 81 F8 04 CD CD CD CD 

L'indirizzo varia ma {133} è sempre la stessa.

Secondo MSDN istruzioni su Come impostare i punti di interruzione sulla allocazione di memoria numero, Io dovrei essere in grado di impostare un punto di interruzione sulla 133rd allocazione con questo appello:

_CrtSetBreakAlloc(133);

e posso anche verificare nella finestra espressioni di controllo che {,,msvcr90d.dll}_crtBreakAlloc è infatti situato a 133.Dopo la chiusura del programma, la perdita di report elenca ancora #133 (insieme con alcuni numeri più alti), ma non un punto di interruzione si verifica.Cosa può essere e come posso fare per ottenere il punto di interruzione si verifica?

Potenzialmente rilevanti info:

1. VS2008, utilizzando il "multi-threaded di debug DLL" CRT
2. Il mio codice è una DLL che viene caricata da un prodotto di terze parti
3. "Normale" punti di interruzione benissimo;passo funziona bene; __asm int 3 funziona troppo bene.
4. Nessun altro valore per _crtBreakAlloc le cause di un punto di interruzione sia (non quelli che ho provato)

5. 133 è il numero più basso nella perdita di report

Answer 1

I principali fronte a schiaffi...Una "evidente" la ragione è, se allocazione #133 si è verificato prima il punto di interruzione è stato impostato...

E ' solo che la prima perdita si rivelasse verificarsi prima che il mio DLL viene richiamato.In realtà non è necessariamente una perdita, perché l'ho chiamata _CrtDumpMemoryLeaks quando la DLL viene scaricata, non quando l'applicazione principale è fatto deinitializing.

Come per "Potenzialmente rilevanti info #4" nella mia domanda originale - beh, ho fatto provare un paio di valori, ma in qualche modo nessuno erano superiori a 133...

Answer 2

Suona come potrebbe essere la compilazione di app e con un non-debug lib, ad esempio.se si utilizza la versione di lib che deve rompere la vostra app, che non lo farà.È possibile che questo accade perché si utilizza l'app 3rd party.È anche possibile che il non-debug dll viene caricata in luogo di debug uno in fase di runtime.

Prova a vedere se il diritto DLL-s vengono caricati per la tua app, mentre il debug e, inoltre, che l'applicazione o DLL è in realtà il debug.(A volte in maniera esplicita di caricare la dll o exe nel debugger.)

Questo è tutto quello che posso pensare senza vedere ulteriori informazioni su questo...