<div dir="ltr">Hi Bill,<div><br></div><div>If you are around today, I should have something for you shortly. If not, we can commit your fix as a temporary one.</div><div><br></div><div>Thanks,</div><div style>-berk</div></div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 11:18 AM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Berk,<div><br></div><div>I can easily reproduce the problem on two different systems. SO when you have a patch ready I can try.</div>

<div>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.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Bill</div><div><br></div></font></span></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 11:10 AM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>




<br></div><div>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.</div>


<span><font color="#888888">

<div><br></div><div>-berk</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 11:00 AM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Berk,<br>
<br>
The current design seems to hinge on the fact that you don't want to<br>
include the Kaapi/OpenMP/etc header files in vtkAtomicIntNN.h.<br>
But is it really such a bad thing to bring in those headers, especially<br>
since the default "Sequential" implementation that most people will<br>
use won't bring any special headers into vtkAtomicIntNN.h at all?<br>
It seems to me that as long as "Internal" is a pointer, there are<br>
going to be static initialization problems.<br>
<span><font color="#888888"><br>
 - David<br>
</font></span><div><div><br>
> On Mon, Aug 26, 2013 at 10:16 AM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>><br>
> wrote:<br>
>><br>
>> Thanks for tracking it btw :-)<br>
>><br>
>><br>
>> On Mon, Aug 26, 2013 at 10:15 AM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>><br>
>> wrote:<br>
>>><br>
>>> Grrr. This is a really annoying issue with using globals like this. It<br>
>>> looks like on that machines, the order of deletion during cleanup is<br>
>>> different and causes this crash. I'll work on this today.<br>
>>><br>
>>> -berk<br>
>>><br>
>>><br>
>>><br>
>>> On Sun, Aug 25, 2013 at 11:57 AM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Looks to me that<br>
>>>> static vtkAtomicInt32 GlobalTimeStamp(0)<br>
>>>><br>
>>>> is being deleted during the finalization before some of the objects have<br>
>>>> been deleted.<br>
>>>><br>
>>>> I verified that by printing out the this pointer in the atomic<br>
>>>> destructor and printing out a message if Increment() is called with an<br>
>>>> Internal = 0.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="im">-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</div></div>
</blockquote></div><br></div>