[Insight-developers] Malloc Debug as Dynamic Coverage?

[Bradley Lowekamp]

On Jul 8, 2009, at 10:58 AM, Sean McBride wrote:
>
>
> Some of those malloc env vars can be added with no problem.  Others
> cause new output to stdout (stderr?) which some tests interpret as a
> test failure (presumably because such output was not expected).

There is also variable to redirect the output of malloc to another  
file, so my experimental is running just fine. I have the heap  
checking going on, it slows down some test significantly but over all  
the timing of all the tests is not bad. I think its only going to take  
4 times as long as a regular testing.

As was pointed out in your bug, it is true that this will just cause  
the test to just fail if a problem is encountered. The additional  
output (when redirected) really can't produce useful analysis, at best  
it would just be an indication of the memory issue detected before an  
abort.

Maybe the mac valgrind is just around the corner :)

>
> What could be very interesting is to run guard malloc.  See 'man
> libgmalloc'.  It causes tremendous slowdown however (as does  
> valgrind).
> I tried it and problems include:
>  - full dashboard takes > 24 hrs (on my hardware)
>  - most tests fail because they take 'too long'
>  - cmake seems to have a non-overridable max test timeout
>
> See also:
> <http://www.vtk.org/Bug/view.php?id=4954>
>
> Then I pretty much gave up.
>
> One thing that would help greatly is if ctest made better use of multi
> core machines.  For example, if I have an 8 core machine, and most of
> the unit tests are single threaded, then most cores are mostly  
> idle.  It
> would be cool if a unit test could report to ctest how many cores it
> needed, then ctest can decide how many independent tests to run at the
> same time.  I suspect that could speed up many dashboards.  Anyone  
> know
> if there is a bug for this?
>
> -- 
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>

========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090708/771cca66/attachment.htm>