Message re-directed from JAC stardev to this more relevant list.
> I'm having problems using fits2ndf. If I use fits2ndf interactively,
> it works fine.
>
> uhppc47.herts.ac.uk> fits2ndf
> IN - Input FITS file(s) [log in to unmask] >
> 1 file selected.
> OUT - Output NDF data structure(s) /@ndf/ >
>
>
> If I do >fits2ndf in out , it doesn't. using the same input file (in).
>
> uhppc47.herts.ac.uk> fits2ndf in=70_plus_70.fits out=ndf_test
> !! Search of free chip stack for a frame match exceeded stack size
> ! DAT_ERASE: Error erasing an HDS structure component.
> ! SUBPAR: Failed to obtain parameter file component for parameter IN
> ! Application exit status DAT__WEIRD, Unknown error
> ! in=70_plus_70.fits out=ndf_test
The parameter files are attached.
On Thu, 18 Oct 2007, Peter W. Draper wrote:
> On Thu, 18 Oct 2007, Peter W. Draper wrote:
>
> > thanks, I can reproduce the problem using those files.
>
> And after a longer look, I'm not much wiser, except it's the
> fits2ndf.sdf file showing the problem this time and it does look just
> like the one we saw before, including going away when run using HDS
> version 3. I'll look a little more but it's one for Brian.
Actually I take some of that back. The fits2ndf parameter file is broken
under HDS version 3 as well (forgot to re-direct ADAM_USER for that test
so was picking up wrong fits2ndf.sdf).
Running under HDS 3 I variously see:
Linux (circa 2004):
% fits2ndf in=ngc1275.fits out=ndf
*** glibc detected *** double free or corruption (!prev): 0x08b38808 ***
Segmentation fault (core dumped)
(gdb) where
#0 0xffffe405 in __kernel_vsyscall ()
#1 0x005527a5 in raise () from /lib/tls/libc.so.6
#2 0x00554209 in abort () from /lib/tls/libc.so.6
#3 0x00586a1a in __libc_message () from /lib/tls/libc.so.6
#4 0x0058d2bf in _int_free () from /lib/tls/libc.so.6
#5 0x0058d63a in free () from /lib/tls/libc.so.6
#6 0x081dd9de in ndf1_wrast_ ()
#7 0x081e8265 in hds1_exit ()
#8 0x081e5c4a in hds1_exit ()
#9 0x081e8c7e in hds1_exit ()
#10 0x081e5954 in hds1_exit ()
#11 0x00555527 in exit () from /lib/tls/libc.so.6
#12 0x08350c5b in astTPNrev ()
Solaris:
> fits2ndf in=ngc1275.fits out=ndf
*** TERMINATING /star/bin/convert/fits2ndf
*** Received signal 11 SIGSEGV
Segmentation fault (core dumped)
(dbx) where
=>[1] _libc_kill(0x0, 0xb, 0x0, 0x0, 0x2105c, 0x3da8f0), at 0x7fa1f930
[2] __f77_sigdie(0xb, 0xffbed9c8, 0xffbed710, 0xffbed64c, 0x21c34, 0x399b30), at 0x3da8f0
[3] 0x399b90(0xb, 0xffbed9c8, 0xffbed710, 0x7fa3c000, 0x0, 0x0), at 0x399b8f
[4] sigacthandler(0xb, 0xffbed9c8, 0xffbed710, 0xc, 0xe, 0x6000), at 0x7fa1e954
---- called from signal handler with signal 11 (SIGSEGV) ------
[5] rec1_update_free(0x0, 0x2, 0xc21930, 0x4f00, 0x0, 0x0), at 0x227554
[6] rec_delete_record(0xffbedc48, 0x4, 0x26b6e8, 0x0, 0x485610, 0xa800), at 0x21a004
[7] dat1_erase_object(0x1, 0xc1f540, 0x7fb50850, 0x0, 0x2, 0x0), at 0x20d4bc
[8] dat_erase_(0x0, 0x0, 0x82aee0, 0xa99c, 0x0, 0x50), at 0x20cef0
[9] subpar_crint_(0x945138, 0x0, 0x945700, 0x0, 0x945144, 0x82aee0), at 0x39ece0
[10] subpar_store0_(0x945138, 0x43e120, 0x945324, 0x945030, 0x945144, 0x82aee0), at 0x3b2cc4
[11] subpar_cmdline_(0x2, 0x945324, 0x945155, 0x82aee0, 0xc, 0x4), at 0x39d9d4
[12] dtask_obeydcl_(0x402cc, 0x3988e0, 0x943964, 0x82aee0, 0xf, 0x1bc), at 0x39896c
[13] dtask_dcltask_(0x40278, 0x402cc, 0x82aee0, 0x0, 0xffbedddc, 0xffbedfd8), at 0x397650
[14] MAIN_(0x14, 0xde6800a, 0x0, 0x10, 0x1b, 0x445570), at 0x40200
[15] main(0x3, 0xffbee13c, 0xffbee14c, 0x490c00, 0x0, 0x0), at 0x402b0
interesting that the Solaris (s/w circa 2002) dies in the same place as
the current puana build does, but without the error message that Tim
added.
So the file must be corrupted, but how?
A hdsdump looks like the previous GLOBAL.sdf problem:
> hdsdump fits2ndf.sdf
HDS dump - BKM/TIMJ 20070725 - file fits2ndf.sdf
HCB information:
HDS version 3, eof block=5
Stack information (LRB)
Block 514, spare 69713
Block 1027, spare 65
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
Block 0, spare 0
....
Peter.
|