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?
David
|