[vtk-developers] Crashes after recent checkins

[Berk Geveci]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130826/9686aa42/attachment.html>