<div dir="ltr">Hi David,<div><br></div><div>I'm not sure that m_Data is nullptr.  I assume its an alias for std::vector of size zero.<br></div><div><br></div><div>I've hit this bug a couple of times.  In visual studio debug mode &std::vector[0] raises an error for vectors of size zero even if that address is never used for anything.  The bug is not in fill_n because the error is raised before fill_n is called.  Calling fill_n with a bogus pointer and size zero is valid. </div><div><br></div><div>On linux the system is happy to generate a bogus pointer thats never used for anything so no valgrind errors are ever generated.</div><div><br></div><div>I recommend checking an if(m_NumElements >0) in pre c++-11.  In c++11 I recommend using the data() method which was added for precisely this reason.</div><div><br></div><div>Hope that helps.</div><div><br></div><div class="gmail_extra"><br clear="all"><div><div>Casey Goodlett</div></div>
<br><div class="gmail_quote">On Fri, Oct 23, 2015 at 1:47 PM, David Cole via Insight-developers <span dir="ltr"><<a href="mailto:insight-developers@itk.org" target="_blank">insight-developers@itk.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It is definitely related to STL being checked in a Debug Visual Studio<br>
build... I get a bunch of ASSERT dialogs that pop up, so the test<br>
times out and hangs there with the dialog up until I kill it manually.<br>
<br>
If I ignore through all the dialogs that pop up (click ignore on each<br>
of them, there are exactly 12 in total), then the test output is<br>
normal, and it reports that it has PASSED.<br>
<br>
I can wait for a fix. I was just asking to see if it was a known<br>
thing, and find out if anybody was working on it, or if there was a<br>
general recommendation about what the right fix for it is before I<br>
attempt to fix it myself.<br>
<br>
I'm curious, though, why is using "&this->m_Data[0]" acceptable if<br>
m_Data is nullptr ...? Why doesn't valgrind pick this up as a problem?<br>
<span><font color="#888888"><br>
<br>
D<br>
</font></span><div><div><br>
<br>
<br>
<br>
On Fri, Oct 23, 2015 at 1:33 PM, Luc Hermitte <<a href="mailto:luc.hermitte@c-s.fr" target="_blank">luc.hermitte@c-s.fr</a>> wrote:<br>
> Hi,<br>
><br>
> Le 23/10/2015 18:43, David Cole via Insight-developers a écrit :<br>
>> The itkTransformTest is the only test failing on my Visual Studio 2013<br>
>> Debug dashboard because of this code:<br>
><br>
> What is the exact error produced when your run the test in verbose mode?<br>
><br>
><br>
>> The problem is in the Fill implementation:<br>
>><br>
>>     template< typename TValue ><br>
>>     void VariableLengthVector< TValue ><br>
>>     ::Fill(TValue const & v) ITK_NOEXCEPT<br>
>>     {<br>
>>       std::fill_n(&this->m_Data[0], m_NumElements, v);<br>
>>     }<br>
>><br>
>> In this test call, m_Data is nullptr, and m_NumElements is 0, so<br>
>> clearly,&m_Data[0] is not a useful pointer, and with 0 elements, there<br>
>> is nothing to fill.<br>
>><br>
>> So.... should the implementation of Fill be changed to be conditional<br>
>> on the pointer being non-nullptr, or the number of elements being<br>
>> non-zero, or both? (Are other Fill implementations protected like so?)<br>
>><br>
>> Or should the test be changed to avoid calling Fill when there are no<br>
>> elements...?<br>
><br>
> I'd say that this is a bug in std::fill_n (or something related to the<br>
> STL being in CHECKED MODE) and that we should fall back into a plain<br>
> loop. We should avoid adding such defensive tests (if (!empty) fill_n()).<br>
><br>
> I can take care of this issue (only on Monday). If you don't mind, I'd<br>
> rather avoid rebasing yet another time and first go through<br>
> <a href="http://review.source.kitware.com/#/c/20253/10" rel="noreferrer" target="_blank">http://review.source.kitware.com/#/c/20253/10</a> (I could also fix the<br>
> issue I've introduced in my first patch on VLV in this patch, but this<br>
> is not the usual patching policy if I understand correctly)<br>
><br>
><br>
> Regards,<br>
> --<br>
> Luc Hermitte<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Kitware offers ITK Training Courses, for more information visit:<br>
<a href="http://kitware.com/products/protraining.php" rel="noreferrer" target="_blank">http://kitware.com/products/protraining.php</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at:<br>
<a href="http://www.itk.org/Wiki/ITK_FAQ" rel="noreferrer" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/insight-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/insight-developers</a><br>
</div></div></blockquote></div><br></div></div>