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.
It is quite possible that there are other potential problems in the
JNIAST C code which sufficiently aggressive multithreaded testing
would reveal, but I don't plan to go looking.
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|