On Thu, 26 Nov 2015 09:03:35 -0500, Timothy Bish <tabish...@gmail.com> wrote:
>On 11/26/2015 08:24 AM, spamtrap wrote: >> On Thu, 26 Nov 2015 07:06:15 -0500, Timothy Bish >> <tabish...@gmail.com> wrote: >> >>> On 11/26/2015 03:07 AM, spamtrap wrote: >>>> On Wed, 25 Nov 2015 11:39:53 -0500, Timothy Bish >>>> <tabish...@gmail.com> wrote: >>>> >>>>> On 11/25/2015 11:29 AM, spamtrap wrote: >>>>>> On Wed, 25 Nov 2015 11:07:53 -0500, Timothy Bish >>>>>> <tabish...@gmail.com> wrote: >>>>>> >>>>>>> On 11/25/2015 10:50 AM, spamtrap wrote: >>>>>>>> On Wed, 25 Nov 2015 09:33:38 -0500, Timothy Bish >>>>>>>> <tabish...@gmail.com> wrote: >>>>>>>> >>>>>>>>> On 11/25/2015 05:47 AM, spam trap wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have the following code: >>>>>>>>>> >>>>>>>>>> cms::Message *pMessage; >>>>>>>>>> ... >>>>>>>>>> std::vector<std::string> propertyNames = >>>>>>>>>> pMessage->getPropertyNames(); >>>>>>>>>> >>>>>>>>>> According to valgrind this leaks memory. propertyNames is on the >>>>>>>>>> stack BTW. >>>>>>>>>> >>>>>>>>>> ==27758== 50,039,920 (289,968 direct, 49,749,952 indirect) bytes in >>>>>>>>>> 6,041 blocks are definitely lost in loss record 383 of 384 >>>>>>>>>> ==27758== at 0x4A075FC: operator new(unsigned long) >>>>>>>>>> (vg_replace_malloc.c:298) >>>>>>>>>> ==27758== by 0x5F77EF9: decaf::util::StlMap<std::string, >>>>>>>>>> activemq::util::PrimitiveValueNode, >>>>>>>>>> decaf::util::comparators::Less<std::string> >::keySet() const >>>>>>>>>> (StlMap.h:866) >>>>>>>>>> ==27758== by 0x5C3799E: >>>>>>>>>> activemq::commands::ActiveMQMessageTemplate<cms::BytesMessage>::getPropertyNames() >>>>>>>>>> const (ActiveMQMessageTemplate.h:109) >>>>>>>>>> >>>>>>>>>> Any ideas? >>>>>>>>>> >>>>>>>>>> >>>>>>>> >From a quick code inspection I don't see any case where a leak can >>>>>>>>> occur. If you can add a test case to the existing set of unit tests >>>>>>>>> for >>>>>>>>> the Message objects to reproduce the valgrind complaint I will look >>>>>>>>> again. >>>>>>>>> >>>>>>>>> Try adding something to >>>>>>>>> src/test/activemq/commands/ActiveMQMessageTest.h/cpp >>>>>>>> Where are the binaries placed for the test programs? I can't seem to >>>>>>>> find them. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Depends on how you are building them, what is the environment and build >>>>>>> process? >>>>>> Linux 64 bit. I've run: >>>>>> >>>>>> configure .... >>>>>> make >>>>>> make install >>>>>> make check >>>>>> >>>>>> >>>>>> >>>>> So on Linux the autotools the build process will place the executables >>>>> in the directory that map to the application being created. >>>>> >>>>> So for instance if you want to build the unit tests the executable is in >>>>> >>>>> ./src/test/ and is called activemq-test I believe. >>>>> >>>>> I generally use a build folder to keep the source and intermediate files >>>>> separate, to test and check for leaks I use a process something like the >>>>> following. >>>>> >>>>> cd activemq-cpp >>>>> mkdir ./build >>>>> ./autogen.sh >>>> I get this: >>>> "configure.ac:122: ' is not a type" >>>> Is this a problem? >>>> >>>>> cd build >>>>> ../configure --enable-shared=no CXXFLAGS="-g -O0" >>>>> make check -j 8 >>>> "make: *** No rule to make target `check'. Stop." >>>> [There's no makefile in the build directory] >>>> >>>> make -f ../Makefile also does not work: >>>> >>>> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh >>>> /home/me/activemq/activemq-cpp-library-3.9.0/config/missing --run >>>> aclocal-1.11 -I m4 >>>> aclocal-1.11: `configure.ac' or `configure.in' is required >>>> make: *** [aclocal.m4] Error 1 >>>> >>>> >>>>> ./src/test/activemq-test >>>> There's no file of this name anywhere. >>>> >>> If you are having trouble try clone the git repo and working with that, >>> I built that code yesterday without issue. >> I've just tried this and I get the same result. I notice that 'make >> check' does not even attempt to build anything in src/test. I wonder >> if it's because cppunit is not installed in a 'standard' location? >> >That could be an issue, you'd need to debug it on your side to find out >for sure. I have built the test programs now and added a test for my case. However I don't see the memory leak being reported by valgrind in the test program -- strange the difference.