On Wed, 1 Jul 2009, David Berry wrote:
> 2009/7/1 Mark Taylor <[log in to unmask]>:
> > On Tue, 30 Jun 2009, Tim Jenness wrote:
> >
> >> On Jun 30, 2009, at 4:56 AM, Mark Taylor wrote:
> >> >
> >> >
> >> > However ... the tests now fail catastrophically (core dump), somewhere
> >> > in FitsChan.write(). Thus a current build should definitely not
> >> > be part of a release. I'll try to track this down, but I'm currently
> >> > in the middle of an AstroGrid release (which ought to be out of the
> >> > way in the next couple of days, though you never know), so it's not
> >> > getting my undivided attention. I'll post here as and when I make
> >> > any progress.
> >>
> >> Strangely I get a segv in SMURF MAKECUBE when I do a simply astShow() on a
> >> fitschan.
> >
> > Interesting.
> >
> >> Begin FitsChan # I/O channels to FITS files
> >> Card = 1 # Index of current card
> >> # Encod = "NATIVE" # Encoding system
> >> # FitsDg = 15 # No. of digits for floating point values
> >> # DfB1950 = 1 # Default to FK4 B1950
> >> # CdMat = 0 # Use PC matrix
> >> # CarLin = 0 # Use full FITS-WCS CAR projections
> >> # Iwc = 0 # Do not include an IWC Frame
> >> # Warn = "Tnx Zpx BadPV BadCel BadMat BadCTYPE" # Warnings to be
> >> reported
> >> <snip>
> >> Dt17 = "REDUCE_SCIENCE" # FITS keyword value
> >> Cm17 = "ORAC-DR recipe" # FITS keyword comment
> >> Nm18 = "DRGROUP" # FITS keyword name
> >> ==2996== Invalid read of size 1
> >> ==2996== at 0x103614AC6: WriteString (channel.c:4558)
> >> ==2996== by 0x1036509E9: Dump (fitschan.c:34536)
> >> ==2996== by 0x10383D046: Dump (object.c:1388)
> >> ==2996== by 0x103615974: Write (channel.c:3715)
> >> ==2996== by 0x10383ED05: Show (object.c:3252)
> >> ==2996== by 0x100073106: smf_fits_outhdr (smf_fits_outhdr.c:226)
> >> ==2996== by 0x10001BB96: smurf_makecube (smurf_makecube.c:1636)
> >> ==2996== by 0x1000026E5: smurf_mon (smurf_mon.c:234)
> >> ==2996== by 0x100002A69: dtask_wrap_ (in /star/bin/smurf/makecube)
> >> ==2996== by 0x10000219A: dtask_applic_ (dtask_applic.f:66)
> >> ==2996== by 0x1040EBF74: dtask_obeydcl_ (in
> >> /star/lib/libdtask_adam.0.0.0.dylib)
> >> ==2996== by 0x1040EA5CF: dtask_dcltask_ (in
> >> /star/lib/libdtask_adam.0.0.0.dylib)
> >>
> >> anything like your segv?
> >
> > not sure, but my problem is more pervasive than just calling astWrite -
> > almost anything done to a FitsChan seems to give a core dump, though
> > other classes seem to work as before. My current best guess is that
> > this has to do with some JNI-specific tricks that I'm playing, so
> > I'm trying to patch it up, but it used to work OK. David, anything
> > spring to mind about changes to the way FitsChan works introduced
> > in the last few months?
>
> Can you give me a date at which you believe it worked correctly - just
> to limit how far back I go?
I backed out of Mark's latest JNI changes and still see the issue, so the
problem isn't very new. The last tested and checked in JNIAST binaries
that I did (which clearly passed the test) are from May 26th. Note if you
look at the dates the Windows update doesn't count, I deliberately did
that from an old sourceset.
There where the changes to fix up support for thread specific data passing
to source and sink functions.
Peter.
|