On Wed, 12 Jan 2011, Mark Taylor wrote:
> On Tue, 11 Jan 2011, Mark Taylor wrote:
>
>> On Tue, 11 Jan 2011, Peter W. Draper wrote:
>>
>>> On Tue, 11 Jan 2011, David Berry wrote:
>>>
>>>>>> It is also possible for the macros to be expanded prior to
>>>>>> compilation (David has a script for that in the AST tree) so that a
>>>>>> more useful line number would turn up.
>>>>>
>>>>> That is probably worth a go.
>>>>
>>>> The script is called "cexpand". For instance, doing
>>>>
>>>> % cexpand frameset.c
>>>>
>>>> will produce a (large!) file called frameset.cpp. This file can be
>>>> compiled as per a normal c file. It is formed by using cpp to expand
>>>> all macros, and then reformatting the result into more readable form.
>>>
>>> That leads us to the context:
>>>
>>> ENSURE_SAME_TYPE(double,jdouble) \
>>> \
>>> /* Ensure that we have all the field and method ID that we may require. */
>>> \
>>> initializeIDs( env ); \
>>> \
>>> /* Decode flags. */ \
>>> flags = (int) (*env)->CallIntMethod( env, jFlags, \
>>> ResampleFlagsGetFlagsIntID ); \
>>>
>>> It is this last line where the crash occurs.
>>
>> Thanks Peter.
>>
>> It looks like the problem is with the initializeIDs function, which
>> is only intended to execute once, getting called simultaneously in
>> multiple threads. The lazy initialization testing it uses is not
>> thread safe. I've moved the invocation of this function from
>> its current (lazy) positions to class static initialization time,
>> where it will only be called once. I've done the same for similar
>> code in some other classes too (Plot, Channel, FitsChan).
>> As far as I can tell this has fixed the problem - I've seen no more
>> core dumps with this change in place, though it's always possible
>> that the run time threading is conspiring to deceive me.
>>
>> Once the svn server is back up I'll commit these changes.
>
> Done (trunk, rev 9679). Peter, over to you to build the native libs
> (again ... sorry for the bug in the first place), and tag it namaka
> when you're done. Depending on how long that's going to take, it
> might make sense to do it on a branch, since I'll want to do some
> unrelated work on the trunk in the near future. Can you let me
> know what your plans are, so I know when it's safe to make other
> commits.
I intended to get this done as soon as possible, but given the delays and
the possibility of holding you back, we should just branch as soon as we
can (tomorrow I'm guessing).
|