[ITK-dev] Bug in the library, or just in the test..?

[David Cole]

It is definitely related to STL being checked in a Debug Visual Studio
build... I get a bunch of ASSERT dialogs that pop up, so the test
times out and hangs there with the dialog up until I kill it manually.

If I ignore through all the dialogs that pop up (click ignore on each
of them, there are exactly 12 in total), then the test output is
normal, and it reports that it has PASSED.

I can wait for a fix. I was just asking to see if it was a known
thing, and find out if anybody was working on it, or if there was a
general recommendation about what the right fix for it is before I
attempt to fix it myself.

I'm curious, though, why is using "&this->m_Data[0]" acceptable if
m_Data is nullptr ...? Why doesn't valgrind pick this up as a problem?


D




On Fri, Oct 23, 2015 at 1:33 PM, Luc Hermitte <luc.hermitte at c-s.fr> wrote:
> Hi,
>
> Le 23/10/2015 18:43, David Cole via Insight-developers a écrit :
>> The itkTransformTest is the only test failing on my Visual Studio 2013
>> Debug dashboard because of this code:
>
> What is the exact error produced when your run the test in verbose mode?
>
>
>> The problem is in the Fill implementation:
>>
>>     template< typename TValue >
>>     void VariableLengthVector< TValue >
>>     ::Fill(TValue const & v) ITK_NOEXCEPT
>>     {
>>       std::fill_n(&this->m_Data[0], m_NumElements, v);
>>     }
>>
>> In this test call, m_Data is nullptr, and m_NumElements is 0, so
>> clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there
>> is nothing to fill.
>>
>> So.... should the implementation of Fill be changed to be conditional
>> on the pointer being non-nullptr, or the number of elements being
>> non-zero, or both? (Are other Fill implementations protected like so?)
>>
>> Or should the test be changed to avoid calling Fill when there are no
>> elements...?
>
> I'd say that this is a bug in std::fill_n (or something related to the
> STL being in CHECKED MODE) and that we should fall back into a plain
> loop. We should avoid adding such defensive tests (if (!empty) fill_n()).
>
> I can take care of this issue (only on Monday). If you don't mind, I'd
> rather avoid rebasing yet another time and first go through
> http://review.source.kitware.com/#/c/20253/10 (I could also fix the
> issue I've introduced in my first patch on VLV in this patch, but this
> is not the usual patching policy if I understand correctly)
>
>
> Regards,
> --
> Luc Hermitte