¿Por qué podría _CrtSetBreakAlloc no causa un punto de ruptura?

Question

Estoy usando rutinas de detección de pérdida de memoria visual de CRT de <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 sobre Cómo establecer puntos de interrupción en memoria del número de asignación , yo debería ser capaz de establecer un punto de interrupción en la asignación de 133 ° con esta llamada:

_CrtSetBreakAlloc(133);

y también puedo verificar en la ventana de reloj que está hecho {,,msvcr90d.dll}_crtBreakAlloc establecido en 133. Después de salir del programa, el informe de fugas aún muestra # 133 (junto con algunos números más altos), pero se produce ningún punto de interrupción. ¿Por qué podría ser esto y cómo puedo conseguir el punto de interrupción que se produzca?

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 "normales" funciona muy bien; pasando a través de las obras excelentes; __asm int 3 funciona muy bien también.
4. No hay otro valor para _crtBreakAlloc hace que sea un punto de interrupción (no los he probado todos modos)

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

Answer 1

Mayor frente bofetadas ... Una de las razones "obvia" es si se ha producido la asignación # 133 antes se establece el punto de interrupción ...

Es sólo que la primera fuga resulta que se produzca antes de que mi DLL se invoca. De hecho no es necesariamente una fuga, ya que llamo _CrtDumpMemoryLeaks cuando se descarga la DLL -. No cuando la solicitud principal se realiza Desinicializando

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 no fueron superiores a 133 ...

Answer 2

Parece que podría estar compilando su aplicación con un lib no depuración, por ejemplo. si utiliza la versión de lanzamiento de la lib que debe romper su aplicación, no va a hacer eso. Es posible que esto se debe a que utilice la aplicación de 3 ª parte. También es posible que el DLL no depuración se carga en lugar de la depuración en tiempo de ejecución.

Trate de ver si el derecho DLL-s se cargan para su aplicación durante la depuración y también que la aplicación o DLL es en realidad depurarse. (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 ...