Perché _CrtSetBreakAlloc potrebbe non causare un punto di interruzione?

Question

Utilizzo le routine di rilevamento perdite di memoria di Visual CRT da <crtdbg.h>; quando chiamo _CrtDumpMemoryLeaks uno allocazione viene segnalata costantemente ad ogni chiamata 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 lo stesso.

secondo le istruzioni del MSDN su How to set breakpoints on memory allocation number, dovrei essere in grado di impostare un punto di interruzione sulla ripartizione 133i con questa chiamata:

_CrtSetBreakAlloc(133); 

e posso verificare anche nella finestra di controllo che {,,msvcr90d.dll}_crtBreakAlloc è infatti impostato a 133 Dopo l'uscita dal programma, il rapporto di perdita elenca ancora # 133 (insieme ad alcuni numeri più alti), ma non si verifica alcun punto di interruzione. Perché questo potrebbe essere e in che modo si verificherà il punto di interruzione?

informazioni potenzialmente rilevanti:

1. VS2008, utilizzando il CRT "multi-threaded di debug DLL"
2. Il mio codice è una DLL che viene caricato da un prodotto di terze parti
3. punti di interruzione "Normale" funziona bene; passare attraverso funziona bene; __asm int 3 funziona bene.
4. Nessun altro valore per _crtBreakAlloc provoca un punto di interruzione o (non quelli che ho provato in ogni modo)

5. 133 è il numero più basso nella relazione perdita

Answer 1

Maggiore fronte schiaffi ... One "ovvio "la ragione è se l'allocazione # 133 si è verificata prima del il punto di interruzione è stato impostato ...

È solo che la prima perdita si verifica prima che la mia DLL venga richiamata. In realtà non è necessariamente una perdita, perché io chiamo _CrtDumpMemoryLeaks quando la DLL viene scaricata - non quando l'applicazione genitore ha terminato la deinizializzazione.

Per quanto riguarda "informazioni potenzialmente rilevanti # 4" nella mia domanda iniziale - così ho provato un paio di valori, ma in qualche modo nessuno era superiore a 133 ...

Answer 2

suona come si potrebbe essere la compilazione tua app con una lib non di debug, es. se usi la versione di rilascio della lib che dovrebbe interrompere la tua app, non lo farà. È possibile che ciò accada perché utilizzi l'app di terze parti. È anche possibile che la DLL non di debug sia caricata al posto di quella di debug in fase di runtime.

Provare a vedere se vengono caricate le DLL corrette per la propria app durante il debug e anche che l'app o la DLL sono effettivamente sottoposte a debug. (A volte è necessario in modo esplicito per caricare la DLL o exe nel debugger.)

Questo è tutto ciò che mi viene in mente senza vedere maggiori dettagli su questo ...