¿Por qué la consola de Windows fuga de aplicación al ralentí? (¿Y por qué el punto de pistola humeante en kernel32.dll ??)

Question

Tengo una aplicación de consola ventanas múltiples threded que parece estar perdiendo memoria privada de aproximadamente 4 kb cada minuto más o menos.

En un esfuerzo para localizar la fuga, me han suspendido gradualmente cada hilo en la aplicación hasta que la fuga se detuvo, y para mi sorpresa el culpable parece ser un hilo llamado "Win32Thread".

No se ve como un hilo que he comenzado de forma explícita.

Si hay que adjuntar y romper la aplicación, el seguimiento de la pila tiene el siguiente aspecto:

    ntdll.dll!_KiFastSystemCallRet@0()  
    ntdll.dll!_NtCancelTimer@8()  + 0xc bytes   
    ntdll.dll!_RtlpResetTimer@12()  + 0x15 bytes    
>   ntdll.dll!_RtlpServiceTimer@12()  + 0xfd bytes  
    ntdll.dll!_KiUserApcDispatcher@16()  + 0x25 bytes   
    kernel32.dll!_BaseThreadStart@8()  + 0x34 bytes 

¿Alguien tiene alguna idea de por qué esto se filtraría repente?

La aplicación como estado funcionando durante aproximadamente un 40hrs en un sistema de doble núcleo Win2k3 SP2.

Cualquier ideas se greately apreciados.

Answer 1

Eso seguimiento de la pila parece que está en el código relacionado con temporizadores. Supongo que su código (o una biblioteca que usa) inicia un temporizador mediante el uso de timeSetEvent o una función similar. En ese caso, la fuga sería probablemente en su función de temporizador de devolución de llamada.

A partir de un temporizador multimedia provoca un hilo que se cree, y su función se le denomina de ese hilo. Un temporizador periódico explicaría por qué se filtra en ralentí.

Answer 2

¿Su aplicación tiene ningún (llamadas a procedimientos asincrónicos) APC o eventos del temporizador programado? Multimedia rutinas de temporización haría.

Si su devolución de llamada utiliza llamadas de tiempo de ejecución C, estas llamadas locales hace que las asignaciones de una sola vez de rosca (con pereza, asignado por primera vez la función se llama en un hilo) para hacer su trabajo (_tcstol, sprintf etc). Debido a que el hilo no se inició con BeginThread () o beginthreadex () esta memoria no puede ser limpiado cuando el hilo muere, de manera que se manifestaría como una fuga.