[Insight-developers] Memory leaks

Karthik Krishnan Karthik.Krishnan at kitware.com
Mon Jun 27 13:44:21 EDT 2005


Thanks Mathieu,

I did change the script a minute ago to post notes to the dashboard. 
Sorry about that..
I was setting GLIBCPP_FORCE_NEW instead of GLIBCXX_FORCE_NEW

Here's the changed script.. Hopefully the valgrind build will look 
cleaner tomorrow.

Thanks
karthik
-----------------------------

SET (CTEST_SOURCE_DIRECTORY 
"/home/karthik/work/ITK/src/Insight/TestingRepository")
SET (CTEST_BINARY_DIRECTORY 
"/home/karthik/work/ITK/binaries/Insight/TestingRepository")


# what cmake command to use for configuring this dashboard
SET (CTEST_CMAKE_COMMAND
  "/usr/bin/cmake"
  )

# Overwrite local modifications while updating
SET (CTEST_CVS_COMMAND "/usr/bin/cvs -dPAC")

SET (CTEST_CVS_CHECKOUT  "${CTEST_CVS_COMMAND} -d 
:pserver:karthik at public.kitware.com:/cvsroot/Insight co -d 
\"${CTEST_SOURCE_DIRECTORY}\" Insight")
SET (CTEST_COMMAND
  "/usr/bin/ctest -T Memcheck -T Submit -D Nightly -I 2,,4 -A 
${CTEST_SCRIPT_DIRECTORY}/${CTEST_SCRIPT_NAME} -I 0,,20"
  )

# should ctest wipe the binary tree before running
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY FALSE)


# this is the initial cache to use for the binary tree, be careful to escape
# any quotes inside of this string if you use it
SET (CTEST_INITIAL_CACHE "

//Command used to build entire project from the command line.

//Balk at the first error with -i
MAKECOMMAND:STRING=/usr/bin/make -i

//make program
CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make

//Name of the build
BUILDNAME:STRING=Linux-g++-3.4-Shared

//Name of the computer/site where compile is being run
SITE:STRING=Sabbath.kitware

BUILD_SHARED_LIBS:BOOL=ON

CVSCOMMAND:FILEPATH=/usr/bin/cvs

BUILD_TESTING:BOOL=ON

# TODO: Add Hans' suppressions file here 
--suppressions=InsightValgrind.supp once its cleaned up
MEMORYCHECK_COMMAND_OPTIONS:STRING=--trace-children=yes --quiet 
--tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=100 
--verbose --demangle=yes

")

# set any extra envionment varibles here
# Get rid of valrgrind STL foolters by forcing STL to use malloc
# and to free memory as soon as possible by globally disabling
# memory caching. Beware! Doing so will probably slow down
# your program, sometimes drastically.
# See http://valgrind.org/docs/FAQ/faq.unexpected.html
SET (CTEST_ENVIRONMENT
 "DISPLAY=:0"
 "GLIBCXX_FORCE_NEW=1"
 "GLIBCPP_FORCE_NEW=1"
)









Mathieu Malaterre wrote:

> Karthik,
>
>     Looking at:
> http://www.itk.org/Testing/Sites/Sabbath.kitware/Linux-g++-3.4-Shared/20050627-0100-Nightly/DynamicAnalysis/__Examples_Segmentation_CannySegmentationLevelSetImageFilterTest.html 
>
> MPK ==9578== 407208 bytes in 49 blocks are still reachable in loss 
> record 2 of 2
> ==9578==    at 0x1B906727: operator new(unsigned) 
> (vg_replace_malloc.c:132)
> ==9578==    by 0x1C5FFA6A: 
> std::__default_alloc_template::_S_chunk_alloc(unsigned, int&) (in 
> /usr/lib/libstdc++.so.5.0.7)
> ==9578==    by 0x1C5FF97C: 
> std::__default_alloc_template::_S_refill(unsigned) (in 
> /usr/lib/libstdc++.so.5.0.7)
> ==9578==    by 0x1C5FF677: 
> std::__default_alloc_template::allocate(unsigned) (in 
> /usr/lib/libstdc++.so.5.0.7)
> ==9578==    by 0x1BD46078: std::__simple_alloc >, 
> std::__default_alloc_template >::allocate(unsigned) (stl_alloc.h:232)
> ==9578==    by 0x1BD4603B: std::_Rb_tree_alloc_base, std::allocator >, 
> true>::_M_get_node() (stl_tree.h:564)
> ==9578==    by 0x1BD46006: std::_Rb_tree_base, std::allocator > 
> >::_Rb_tree_base(std::allocator > const&) (stl_tree.h:579)
> ==9578==    by 0x1BD45FB7: std::_Rb_tree, std::_Select1st >, 
> std::less, std::allocator > >::_Rb_tree(std::less const&, 
> std::allocator > const&) (stl_tree.h:730)
> ==9578==    by 0x1C53131C: std::map, std::allocator > >::map() 
> (stl_map.h:144)
>
>
>
>     It seems you did not defined GLIBCXX_FORCE_NEW or 
> GLIBCPP_FORCE_NEW. Could you please include the ctest script you are 
> using as a note (ctest -A) or post it to the list.
>
> Thanks
> Mathieu
> Ref:
> http://valgrind.org/docs/FAQ/faq.unexpected.html#faq.reports
>
>
>
> Karthik Krishnan wrote:
>
>> Sabbath submits valgrind builds.
>> http://www.itk.org/Testing/Sites/Sabbath.kitware/Linux-g++-3.4-Shared/20050627-0100-Nightly/DynamicAnalysis.html 
>>
>> Since the tests take a long time, its broken into 4 day cycles.
>>
>> Thanks
>> Regards
>> Karthik
>>
>>
>>> We have not had purify runs for several months. Our systems cannot 
>>> complete the runs overnight. We should see how valgrind performs. 
>>> I'm really uncomfortable that we are not running nightly memory 
>>> tests. Dart2 may help.
>>>
>>> Bill
>>>
>>> -----Original Message-----
>>> From: insight-developers-bounces+lorensen=crd.ge.com at itk.org 
>>> <http://www.itk.org/mailman/listinfo/insight-developers>
>>> [mailto:insight-developers-bounces+lorensen=crd.ge.com at itk.org 
>>> <http://www.itk.org/mailman/listinfo/insight-developers>]On Behalf
>>> Of Luis Ibanez
>>> Sent: Wednesday, June 15, 2005 4:08 PM
>>> To: Kent Williams
>>> Cc: insight-developers at itk.org 
>>> <http://www.itk.org/mailman/listinfo/insight-developers>; Mathieu 
>>> Malaterre
>>> Subject: Re: [Insight-developers] how to attack memory leaks
>>>
>>>
>>>
>>> Kent,
>>>
>>> That's great,
>>>
>>> Maybe we should put together a ValgridnSuppresion.supp
>>> file for ITK and maintain it in the CVS repository.
>>>
>>> It seems that there are similar files already in CMake and
>>> VTK but each one is a bit tailored to their own project.
>>>
>>> We could start by combining Kent's file from Brains2 and
>>> the one available in GDCM in Insight/Utilities/gdcm/CMake.
>>>
>>>
>>> Any suggestions as to where to put this file in the ITK
>>> directory ?
>>>
>>>
>>>
>>>     Luis
>>>
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>


More information about the Insight-developers mailing list