¿Por qué _CrtSetBreakAlloc podría no causar un punto de interrupción?

Question

Estoy usando rutinas de detección de pérdida de memoria de Visual CRT desde <crtdbg.h>; cuando llamo _CrtDumpMemoryLeaks una asignación se informó consistentemente en cada llamada del programa:

{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 

La dirección varía, pero {133} es siempre la misma.

De acuerdo con las instrucciones del MSDN en How to set breakpoints on memory allocation number, yo debería ser capaz de establecer un punto de interrupción en la asignación de 133 ° con esta llamada:

_CrtSetBreakAlloc(133); 

y yo también se puede verificar en la ventana de reloj que {,,msvcr90d.dll}_crtBreakAlloc es de hecho establece en 133 Después de que el programa finaliza, el informe de fugas aún muestra el n. ° 133 (junto con algunos números más altos), pero no se produce ningún punto de interrupción. ¿Por qué podría ser esto y cómo puedo obtener el punto de interrupción?

información potencialmente relevante:

1. VS2008, utilizando el CRT "multi-hilo de depuración DLL"
2. Mi código es un archivo DLL que se carga mediante un producto de terceros
3. puntos de ruptura "normal" funciona bien; caminar funciona bien; __asm int 3 funciona bien también.
4. Ningún otro valor para _crtBreakAlloc provoca un punto de interrupción o bien (no los que he intentado de todas formas)

5. 133 es el número más bajo en el informe de fugas

Answer 1

Mayor frente bofetadas ... Una "obvia "razón es si la asignación n. ° 133 se produjo antes de se estableció el punto de interrupción ...

Es solo que la primera fuga se produce antes de que se invoca mi DLL. De hecho, no es necesariamente una fuga, porque llamo al _CrtDumpMemoryLeaks cuando la DLL está descargada, no cuando la aplicación principal está lista para desinicializar.

En cuanto a la "información potencialmente relevante # 4" en mi pregunta original - así lo hice probar un par de valores, pero de alguna manera ninguno fue mayor que 133 ...

Answer 2

suena como que podría estar compilando su aplicación con una libre de depuración, por ej. si usa la versión de lanzamiento de la lib que debe romper su aplicación, no hará eso. Es posible que esto ocurra porque utilizas la aplicación de terceros. También es posible que el dll que no es de depuración se cargue en lugar del depurador en el tiempo de ejecución.

Trate de ver si se cargan las DLL-s correctas para su aplicación durante la depuración y también que la aplicación o la DLL están realmente depuradas. (A veces hay que explícitamente para cargar el archivo DLL o EXE en el depurador.)

Esto es todo lo que puedo pensar sin ver más detalles acerca de esto ...