[vtk-developers] vtk-developers Digest, Vol 112, Issue 33

[Andrew Maclean]

Hi Berk, Sean,
  Since I was the author of this test, let me know if there is anything I
can do to help.

The intent of this test was to test as much as possible of the
vtkNamedColors class - I think I achieved around 100%.

Lines 890-901 specifically test PrintSelf(). PrintSelf() seems to be rarely
tested so initially I expected some problems, however this is the first
time I have seen anything.

Like Berk, I don't understand why this would fail on one machine but not
others.

Regards
   Andrew

---------- Forwarded message ----------
> From: Berk Geveci <berk.geveci at kitware.com>
> To: Sean McBride <sean at rogue-research.com>
> Cc: VTK Developers <vtk-developers at vtk.org>
> Date: Wed, 28 Aug 2013 13:31:19 -0400
> Subject: Re: [vtk-developers] vtkCommonColorCxx-TestNamedColors test
> failure, git bisected to atomic int changes
> I am going to track it down. Ultimately, it is a crappy test that depends
> on the output of PrintSelf() which fails when things like MTime changes.
> Nevertheless, I need to figure out why the MTime changed on some platforms
> and not others.
>
> -berk
>
>
> On Wed, Aug 28, 2013 at 12:52 PM, Sean McBride <sean at rogue-research.com>wrote:
>
>> Berk,
>>
>> The vtkCommonColorCxx-TestNamedColors test passed here:
>>
>> <http://open.cdash.org/testDetails.php?test=193771179&build=3005399>
>>
>> and started failing here:
>>
>> <http://open.cdash.org/testDetails.php?test=204990005&build=3006482>
>>
>> I used git bisect, and it points to this:
>>
>> ---------------------
>> 8d3f2756c9025012320c1e65288f6006d9acd7a8 is the first bad commit
>> commit 8d3f2756c9025012320c1e65288f6006d9acd7a8
>> Author: Berk Geveci <berk.geveci at kitware.com>
>> Date:   Wed Aug 21 12:08:17 2013 -0400
>>
>>     Implements a few improvements for the atomic integers.
>>
>>     The main concern on the mailing list was that some of the
>>     implementation was not using memory barriers/fences, which
>>     may be dangerous in some cases. I made the first attempt to
>>     make much of the atomic functionality use a sequentially-
>>     consistent ordering by using memory barriers. The performance
>>     impact seems to be relatively small but we will have to keep
>>     an eye on it.
>>
>>     I also made some changes to the implementation that will
>>     hopefully avoid falling back to critical sections on Windows
>>     XP.
>>
>>     Change-Id: Ib05f411f905cfe9a89bb8bc82ca103d3c1eb8002
>> ---------------------
>>
>> The verbose test output is:
>>
>> ---------------------
>> 176: Test command:
>> /Users/builder/external/VTK-clang-rel-x86_64/bin/vtkCommonColorCxxTests.app/Contents/MacOS/vtkCommonColorCxxTests
>> "TestNamedColors" "-D"
>> "/Users/builder/external/VTK-clang-rel-x86_64/ExternalData/Testing" "-T"
>> "/Users/builder/external/VTK-clang-rel-x86_64/Testing/Temporary"
>> 176: Test timeout computed to be: 1500
>> 176: Generic Warning: In
>> /Users/builder/external/VTK/Common/Color/Testing/Cxx/TestNamedColors.cxx,
>> line 899
>> 176: Fail: PrintSelf() - a string of size 9243 was expected, got 9261
>> instead.
>> 176:
>> 1/1 Test #176: vtkCommonColorCxx-TestNamedColors ...***Failed    0.15 sec
>> ---------------------
>>
>> Cheers,
>>
>> --
>> ____________________________________________________________
>> Sean McBride, B. Eng                 sean at rogue-research.com
>> Rogue Research                        www.rogue-research.com
>> Mac Software Developer              Montréal, Québec, Canada
>>
>>
>>
>
-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130830/71b01802/attachment.html>