What steps will reproduce the problem?
1. run mdpsim on some domain (tested on coffee-domain)
2. run a client with valgrind:
valgrind --tool=memcheck --leak-check=full /path/to/client --port=2323
--host=localhost /path/to/coffee-domain.pddl /path/to/coffee-problem.pddl
3. notice the memory leak in valgrind's output due to the non deletion of
the local variable: XMLText *t = new XMLText(text);
==17656==
==17656== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 1)
==17656== malloc/free: in use at exit: 66,102 bytes in 4,518 blocks.
==17656== malloc/free: 694,454 allocs, 689,936 frees, 18,856,192 bytes
allocated.
==17656== For counts of detected errors, rerun with: -v
==17656== searching for pointers to 4,518 not-freed blocks.
==17656== checked 119,380 bytes.
==17656==
==17656==
==17656== 49,676 (18,064 direct, 31,612 indirect) bytes in 2,258 blocks are
definitely lost in loss record 2 of 3
==17656== at 0x4022F0C: operator new(unsigned) (vg_replace_malloc.c:163)
==17656== by 0x4051A45: PSink::pushText(std::string const&) (strxml.cc:218)
==17656== by 0x4053D20: read_node(int) (strxml.cc:187)
==17656== by 0x404F4A3: XMLClient::XMLClient(Planner&, Problem const&,
std::string const&, int) (client.cc:316)
==17656== by 0x804B3D8: main (main_caylus.cc:288)
==17656==
==17656== LEAK SUMMARY:
==17656== definitely lost: 18,064 bytes in 2,258 blocks.
==17656== indirectly lost: 31,612 bytes in 2,258 blocks.
==17656== possibly lost: 0 bytes in 0 blocks.
==17656== still reachable: 16,426 bytes in 2 blocks.
==17656== suppressed: 0 bytes in 0 blocks.
==17656== Reachable blocks (those to which a pointer was found) are not shown.
==17656== To see them, rerun with: --leak-check=full --show-reachable=yes
What is the expected output? What do you see instead?
valgrind should report no memory leak. I don't know where this variable
should be deleted. Function PSink::pushNode is very similar but valgrind
does not report any memory leak with this function.
What version of the product are you using? On what operating system?
mdpsim-2.2.2
Please provide any additional information below.
Original issue reported on code.google.com by florent....@gmail.com on 25 Mar 2008 at 7:23
Original issue reported on code.google.com by
florent....@gmail.com
on 25 Mar 2008 at 7:23