Memory leak detected
cybersecurityworks553 opened this issue · 3 comments
A memory leak has been detected on mxml_new and mxmlNew functions in mxml-code.c file.
To reproduce, compile the code with following commands
AFL_USE_ASAN=1 ./configure CC=afl-gcc CXX=afl-g++ LD=afl-gcc--disable-shared
AFL_USE_ASAN=1 make
=================================================================
==8321==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 88 byte(s) in 1 object(s) allocated from:
#0 0x7f6807fcfce6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
#1 0x565528729344 in mxml_new /home/mxml/mxml-node.c:841
#2 0x565528729344 in mxmlNewElement /home/mxml-node.c:382
#3 0x7ffd2b9fc4ff ([stack]+0x1a4ff)
Indirect leak of 37 byte(s) in 1 object(s) allocated from:
#0 0x7f6807f583dd in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x963dd)
#1 0x5655287294d5 in mxmlNewElement /home/mxml/mxml-node.c:383
What version of Mini-XML?
Is this just with the "testmxml" program and test file bundled with Mini-XML, or ???
Is this an actual memory leak or just memory that was not freed before exit?
Affected version 3.2. (Latest)
It is in Mini-XML Library not on testmxml. You can reproduce by running the above commands.
It was not freed before exit.
OK, so running "make" also runs "testmxml" as part of the build.
And if this is a "test program doesn't explicitly free an allocated object" bug, that is NOT a bug. Unless you need to call an object's destructor to do some sort of cleanup, it is a waste of CPU to explicitly free things before you exit (which returns all memory to the OS).