[vtk-developers] Crashes after recent checkins

[Bill Lorensen]

I'm around all day.



On Mon, Aug 26, 2013 at 11:25 AM, Berk Geveci <berk.geveci at kitware.com>wrote:

> Hi Bill,
>
> If you are around today, I should have something for you shortly. If not,
> we can commit your fix as a temporary one.
>
> Thanks,
> -berk
>
>
> On Mon, Aug 26, 2013 at 11:18 AM, Bill Lorensen <bill.lorensen at gmail.com>wrote:
>
>> Berk,
>>
>> I can easily reproduce the problem on two different systems. SO when you
>> have a patch ready I can try.
>> However, I will be offline for a few days (Tues-Thurs) this week. If you
>> can't find a good solution quickly, perhaps we could use my patch as a
>> temporary fix, or backout the atomic stuff until it is ready.
>>
>> Bill
>>
>>
>>
>> On Mon, Aug 26, 2013 at 11:10 AM, Berk Geveci <berk.geveci at kitware.com>wrote:
>>
>>> Bill & David: To me, the actual issue to fix is the one in vtkTimeStamp.
>>> Both Bill's fix and what David is suggesting still hinge on using a
>>> destroyed object, which makes me a little uncomfortable. So I think that
>>> the right fix is one that does not access the static object in the
>>> Modified() call. So let me think about a way of solving that problem and
>>> bounce it around for review.
>>>
>>> David: The main reason I used the Internal member was to avoid
>>> duplicating the header files in the subdirectories. Currently, they are
>>> shared by all implementation. The alternative would be to not use
>>> subdirectories and use the preprocessor I guess. Or to duplicate the header
>>> files.
>>>
>>> -berk
>>>
>>>
>>> On Mon, Aug 26, 2013 at 11:00 AM, David Gobbi <david.gobbi at gmail.com>wrote:
>>>
>>>> Hi Berk,
>>>>
>>>> The current design seems to hinge on the fact that you don't want to
>>>> include the Kaapi/OpenMP/etc header files in vtkAtomicIntNN.h.
>>>> But is it really such a bad thing to bring in those headers, especially
>>>> since the default "Sequential" implementation that most people will
>>>> use won't bring any special headers into vtkAtomicIntNN.h at all?
>>>> It seems to me that as long as "Internal" is a pointer, there are
>>>> going to be static initialization problems.
>>>>
>>>>  - David
>>>>
>>>> > On Mon, Aug 26, 2013 at 10:16 AM, Berk Geveci <
>>>> berk.geveci at kitware.com>
>>>> > wrote:
>>>> >>
>>>> >> Thanks for tracking it btw :-)
>>>> >>
>>>> >>
>>>> >> On Mon, Aug 26, 2013 at 10:15 AM, Berk Geveci <
>>>> berk.geveci at kitware.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> Grrr. This is a really annoying issue with using globals like this.
>>>> It
>>>> >>> looks like on that machines, the order of deletion during cleanup is
>>>> >>> different and causes this crash. I'll work on this today.
>>>> >>>
>>>> >>> -berk
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Sun, Aug 25, 2013 at 11:57 AM, Bill Lorensen <
>>>> bill.lorensen at gmail.com>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> Looks to me that
>>>> >>>> static vtkAtomicInt32 GlobalTimeStamp(0)
>>>> >>>>
>>>> >>>> is being deleted during the finalization before some of the
>>>> objects have
>>>> >>>> been deleted.
>>>> >>>>
>>>> >>>> I verified that by printing out the this pointer in the atomic
>>>> >>>> destructor and printing out a message if Increment() is called
>>>> with an
>>>> >>>> Internal = 0.
>>>>
>>>
>>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>>
>
>


-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130826/89c0de0b/attachment.html>