View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

ccdproc + broken pipe

SteveSchulze wrote on Feb 23, 2012

Hello,

I use IRAF as a part of Scisoft 7.5 on Ubuntu. Recently, I encountered the following problem, although IRAF worked smoothly on the computer for a long time (more than a year).

- --> epar ccdproc

Task ccdproc is running...

x_ccdred.e: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
__builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) ||
((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof
(struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) &
~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) &&
((unsigned long)old_end & pagemask) == 0)' failed.

PANIC in `/scisoft/share/iraf/iraf/noao/bin.redhat/x_ccdred.e': Memory
has been corrupted
Killing IRAF task `ccdproc'
Exception in Tkinter callback
Traceback (most recent call last):
File "/scisoft/lib/python2.5/lib-tk/Tkinter.py", line 1414, in __call__
return self.func(*args)
File "/scisoft/lib/python2.5/site-packages/pytools/editpar.py", line
1072, in execute
self.runTask()
File "/scisoft/lib/python2.5/site-packages/pytools/editpar.py", line
1462, in runTask
self._taskParsObj.run(mode='h', _save=1)
File "/scisoft/lib/python2.5/site-packages/pyraf/iraftask.py", line
302, in run
self._run(redirKW, specialKW)
File "/scisoft/lib/python2.5/site-packages/pyraf/iraftask.py", line
744, in _run
"\n" + str(value))
IrafError: Error running IRAF task ccdproc
('Not a legal IRAF pipe record', 32, 'Broken pipe')

Do you know what might cause this problem, or what I could check?

Thanks.

Steve

Mike Fitzpatrick wrote on Feb 23, 2012

The error message indicates a memory corruption problem in CCDPROC, but that's about all. Since this is a v2.14.1 system you'd have to confirm the same problem is present in v2.15 and provide the data and params so we could try to reproduce it. If your IRAF system hasn't changed, it may be a data-specific problem you could isolate, e.g. invalid CCDSEC values or a corrupted file. Does the behavior change as you enable/disable individual parameters? Does it make a difference if you run the task under the CL instead of PyRAF? Does it work correctly on a different but similar machine (i.e. it is rare, but a bad memory chip could be the cause as well).

Last post on Feb 23, 2012