GNOME Bugzilla – Bug 501883
Memory leak in __xmlGlobalInitMutexLock on Windows
Last modified: 2007-12-06 09:59:33 UTC
Please describe the problem: The function __xmlGlobalInitMutexLock has a small memory leak on Windows (there's no leak on other OS's). The relevant code (from CVS head as of Dec 5th 2007) is as follows: ----------------- #elif defined HAVE_WIN32_THREADS LPCRITICAL_SECTION cs; /* Create a new critical section */ if (global_init_lock == NULL) { cs = malloc(sizeof(CRITICAL_SECTION)); ----------------- The 'cs' object never seems to get freed. This was detected by a memory leak detection tool on Windows XP running libxml version 2.6.29. However I've looked at the latest code in CVS and it doesn't look like the leak has been fixed. The leak is very small (24-bytes) and only seems to occur a single time, so it's not a huge deal. Still, I figured I'd report it. Steps to reproduce: Below is a small program that will reproduce the memory leak. It includes some code to turn on leak detection in Microsoft's CRT. ----------------- #include <libxml/xmlreader.h> // Headers for memory leak checking #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> int main() { // Enable memory leak checking _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF | _CRTDBG_CHECK_EVERY_1024_DF); xmlInitParser(); xmlCleanupParser(); return 0; } Actual results: I get a 24-byte memory leak. Expected results: No leak. Does this happen every time? Yes. Other information: This was detected and reported by a user of the Collada DOM in this thread: https://collada.org/public_forum/viewtopic.php?p=3312&sid=513a44216e418eaa6f875c5215aff156#3312
This was fixed a few weeks ago in revision 3664.