[vtk-developers] Dashboard test failure question

[David Gobbi]

I understand.  However, if the bug isn't fixed and there is a very low
probability that it every will be fixed, it should be marked as "won't fix"
instead of being marked as "fixed".

So I'm just wondering how it came to pass that the bug is marked as
fixed, when it isn't.

  David


On Fri, Jan 17, 2014 at 12:11 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> I'm pretty sure that did not fix the bug.
>
> We spent a lot of time on this one. The volume rendering code is old
> and tough to follow.
>
>
>
> On Fri, Jan 17, 2014 at 1:38 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> I went back to the bug report on this multi-threading issue, and oddly
>> enough the bug is marked as "fixed":
>> http://www.vtk.org/Bug/view.php?id=13420
>>
>> A note in the bug report says "Was fixed in commit: e4a793c47cc3"
>> But I looked at the commit, and it seems to be unrelated.  Why was
>> the bug closed, when the problem still exists?  Was it closed
>> accidentally?
>>
>>   David
>>
>>
>> On Fri, Jan 17, 2014 at 10:40 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> On Fri, Jan 17, 2014 at 10:07 AM, David Cole <dlrdave at aol.com> wrote:
>>>>
>>>> If that warning is true, then shouldn't any test that uses that class set
>>>> the number of threads to 1 instead of trying to use all the cores available
>>>> on a machine......?
>>>
>>> Bill already fixed a bunch of tests to set NumberOfThreads=1 for this
>>> mapper.  TestSmartVolumeMapperWindowLevel must have slipped through
>>> the cracks.
>>>
>>>> Does anybody really want non-repeatable results?
>>>
>>> Fixing the bug in the mapper would be the correct way of ensuring
>>> repeatable results: it's a multi-threaded mapper, but running it
>>> with too many threads causes artifacts.  In my view, the
>>> "SetNumberOfThreads(1)" trick is a way of sweeping the problem
>>> under the rug, out of sight and out of mind.
>>>
>>>   David