On Mon, 10 Jan 2011, Peter W. Draper wrote:
> On Mon, 10 Jan 2011, David Berry wrote:
>
> > On 7 January 2011 18:32, Peter W. Draper <[log in to unmask]> wrote:
> > > On Fri, 7 Jan 2011, Mark Taylor wrote:
> > >
> > > > On Fri, 7 Jan 2011, Peter W. Draper wrote:
> > > >
> > > > > > Having done all that ... running the JNIAST unit tests is now giving
> > > > > > me occasional core dumps :-(. This is probably a threading issue -
> > > > > > the SEGVs are in uk.ac.starlink.ast.ThreadTest. I've attached an
> > > > > > example dump file. Difficult to reproduce, currently happening
> > > > > > something like one time in ten, but in the way of these things it
> > > > > > seems to go away if you just run the test ten times. I don't
> > > > > > *think* this problem is present in the build before these changes.
> > > > > > It looks to me unlikely that the changes I've just made to JNIAST
> > > > > > would cause this (though I can't say it's impossible), which
> > > > > > suggests it's to do with how it's built. The builds I've done have
> > > > > > been against hawaiki (AST 5.3-1) or nanahope (AST 5.2-0) - I don't
> > > > > > have a 5.1-0 to hand. So, it could be version issues. I suspect
> > > > > > however that it might go away if it's built against an AST built
> > > > > > without threading. Although I believe/believed that JNIAST ought to
> > > > > > work with a multithreaded AST, it doesn't actually benefit much from
> > > > > > multithreaded AST (see comments in jniast.h for the sorry tale), so
> > > > > > this wouldn't have much of a downside (and the previous build might
> > > > > > well have been against a threadless AST, though I'm not sure if it
> > > > > > was or not). If we can't resolve this we should put the changes
> > > > > > back on a branch or otherwise roll them back - it is not safe to
> > > > > > leave them without a native library rebuild, since the java and C
> > > > > > sides of the JNI code do not quite match when using the old native
> > > > > > libs.
> > > > >
> > > > > Hi Mark & David,
> > > > >
> > > > > OK, I've rebuilt JNIAST against the latest AST (5.4) and this problem
> > > > > is still there, and it's repeatable as in I get to the same line of
> > > > > code each time, and it seems likely to be the same one that Mark's
> > > > > dump shows:
> > > > >
> > > > > 1225: MAKE_RESAMPLEX(I,int,jint,Int,I)
> > > > >
> > > > > in Mapping.c.
> > > > >
> > > > > Must be worth one of you looking at that macro for any shared
> > > > > resources that are not being locked (there are some structs malloc
> > > > > outside of any locks I can see, or David worrying about astResample,
> > > > > but I imagine that is heavily used?).
> > > > >
> > > > > I'd prefer not to require a non-threaded AST library as that will mean
> > > > > we cannot build against a standard tree (that is bound to come back as
> > > > > a problem).
> > > >
> > > > I did a bit more investigation, and it turns out that contrary to my
> > > > assessment above, the same issue can show up in the existing JNIAST, so
> > > > this has been lurking for a while, i.e. before the FitsChan-related
> > > > fixes suggested by David. I'm not sure why I haven't seen the failure
> > > > before, but likely it's just that the last time I was doing JNIAST work
> > > > I had a different machine and it just never hit the relevant race
> > > > condition. On the bright side, as far as I know nobody has come across
> > > > this issue in real life - probably nobody is doing massively
> > > > multithreaded JNIAST.
> > > >
> > > > So, the new build is (most likely) no worse than the one we had before.
> > > > It's quite possible that a non-threaded AST wouldn't even help.
> > >
> > > Sorry should have at least tested that idea, but it seems getting a
> > > non-threaded AST isn't possible:
> > >
> > > ./configure --without-pthreads
> > > make
> > > .....
> > > channel.c: In function 'ReadDouble':
> > > channel.c:2796: error: 'AST__BAD' undeclared (first use in this function)
> > > channel.c:2796: error: (Each undeclared identifier is reported only once
> > > channel.c:2796: error: for each function it appears in.)
> > > channel.c: In function 'WriteDouble':
> > > channel.c:3989: error: 'AST__BAD' undeclared (first use in this function)
> > > make[1]: *** [libast_la-channel.lo] Error 1
> > > make[1]: Leaving directory
> > > `/loc/pwda/pdraper/starlink_git/starlink/libraries/ast'
> > > make: *** [all] Error 2
> >
> > A few missing includes - should be OK now.
>
> And the result is that this error is also present with an unthreaded AST build
> as well. So this problem is probably not related to AST threads.
Thanks for checking that out, and sorry for the red herring.
> Given that I'd suggest that we just build against threaded AST and Mark takes
> a note to look at this sometime.
OK, but note that sometime may not be soon.
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|
