On 11/27/2015 03:38 AM, spam trap wrote:
> 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.
>
>
Makes sense to check your application to ensure you are freeing message
instances as that could lead to a leak of this area being reported.
--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.b...@redhat.com | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/
