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.
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?
For reference gdb says that it's calling WriteString with "Ty18" but
with a value whose address is out of bounds.
WriteString (this=0x104458008, name=0x7fff5fbfcf00 "Ty18", set=3,
helpful=1, value=0x4d555458 <Address 0x4d555458 out of bounds>,
comment=0x103944c5f "FITS keyword data type", status=0x7fff5fbfdb5c)
at channel.c:4558
4558 for ( i = 0; value[ i ]; i++ ) {
This is called from fitschan.c as:
34536 astWriteString( channel, buff, 1, 1, type_names[ cardtype ],
After some digging, it turns out that AST does not actually know what
to do with type_names when the card is returned as type 8 (UNDEFINED).
So my problem is related to doing a dump of a FitsChan with undefined
values in cards.
David - I've pushed a fix. I've also done a small amount of consting
in fitschan.c and channel.c to fix compiler warnings. There are some
dodgy uses remaining where a char * can interchangeably store a char *
or a const char * but I haven't fixed anything controversial (I don't
think)..
--
Tim Jenness
Joint Astronomy Centre
|