Pourquoi l'application de ma console Windows fuit-elle au ralenti? (Et pourquoi est-ce que le pistolet fumant pointe à kernel32.dll ??)

Question

J'ai une application de console multi-Thread de Windows qui semble fuir environ 4 Ko de mémoire privée toutes les minutes. Dans un effort pour localiser la fuite, j'ai progressivement suspendu chaque thread dans l'application jusqu'à ce que la fuite s'arrête, et à ma grande surprise, le coupable semble être un thread nommé "Win32Thread".

Cela ne ressemble pas à un fil que j'ai explicitement démarré.

Si j'attache et briser l'application, la trace de la pile ressemble à ceci:

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 

Est-ce que quelqu'un a une idée pourquoi ce serait soudainement une fuite?

L'application fonctionne depuis environ 40 heures sur un système dual core Win2k3 SP2.

Toutes les idées sont grandement appréciées.

Answer 1

Cette trace de pile ressemble à du code associé aux minuteurs. Je suppose que votre code (ou une bibliothèque que vous utilisez) a démarré une minuterie en utilisant timeSetEvent ou une fonction similaire. Dans ce cas, la fuite serait probablement dans votre fonction de rappel de minuterie. Le démarrage d'un minuteur multimédia entraîne la création d'un thread et l'appel de ce dernier à partir de ce thread. Une minuterie périodique expliquerait pourquoi elle fuit pendant la marche au ralenti.

Answer 2

Votre application a-t-elle des APC (appels de procédure asynchrones) ou des événements programmés? Les rappels de minuterie multimédia le feraient. Si votre callback utilise des appels C runtime, ces appels permettent d'effectuer des allocations locales de threads uniques (paresseusement, alloués la première fois que la fonction est appelée dans un thread) pour faire leur travail (_tcstol, sprintf, etc.). Étant donné que le thread n'a pas été démarré avec beginthread() ou beginthreadex(), cette mémoire ne peut pas être nettoyée lorsque le thread meurt, ce qui se traduit par une fuite.