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