iraf.net

I've had reports of Scisoft's IRAF (2.14, 32-bit) causing OS X Leopard
to freeze up, but only on certain systems. Test code, abstracted from
real-life problem case, of form:imexpr "a > 1e7 ? 1 : 0" test.fits data/infileNNN.fits[M]del test.fits.... looping on M (1 to 3) and NNN (1 to 69). IRAF freezes, and
system has to be power-cycled.The only thing in common between the afflicted systems is the hard
drive model: Hitachi HDS721010KLA330. I can reproduce the fault at will
with IRAF, but nothing else I've thrown at them causes the fault, and
Apple's diagnostics see no problems. Changing the drive causes the
problem to go away, but we've a seriously large number of iMacs
with this drive model, and I'd rather not void their warranties
quite yet.Suggestions, please. Apologies for any formatting botches above.

IRAF doesn't really do anything different than any other C program that reads/writes files to disk, and certainly nothing at a level specific to a particular drive model. It's hard to tell from your message exactly how 'freeze' is defined, i.e. is the CPU or disk pegged at 100%? Does the keyboard/mouse stop responding? Are there any messages in the system logs indicating a hardware fault? Does the error always happen on the same image? What happens if you leave that image out, is it always the Nth image in the list? Even if the list is always the same image? Are all 3 extensions images? Are these Intel or PPC iMacs?

Apologies for not being more specific:System: iMacs and Mac Pros, all Intel, running Leopard or Snow Leopard.Freeze: IRAF hangs. Disk and CPU activity die away to zero immediately
(as shown by Activity Monitor). Other window activity continues awhile.
Nothing more can be started by mouse; many programs started subsequently
at command line (eg ps) yield a hanging shell; system cannot be shut down.
Nothing obvious in logs on reboot.First user reported particular images causing problem, then retracted. I found
changing the sampling period on Activity Monitor affects which image the
problem happens on.Hope that helps.

Without having a problem system literally in front of me I'm afraid there's not much I can do. If this were a single system I would suspect a hardware problem (logic board, bad RAM, bad disk, etc) but if it's across a number of machines it might be something else.SciSoft normally just repackages the binaries we produce but creates it's own environment variable. When you login to the CL and issue a[code:1:d33f4de602]cl> !env[/code:1:d33f4de602]Do you see a 'mach', 'MACH' or 'arch' environment variable that is something other than 'macintel' (or '.macintel' for $arch) ?? I'm wondering whether you're somehow using the PPC binaries (e.g. does a 'ps' show 'macosx' in the pathname to x_images.e)?As I said, IRAF does basic I/O and computation. You might try attaching a debugger to the x_images.e once it is running to see if it catches an error, otherwise there's not much more I can offer than to suggest you Google around for similar problems. Some of the stuff I found in a quick search:http://discussions.info.apple.com/message.jspa?messageID=9901840http://www.finetunedmac.com/forums/ubbthreads.php?ubb=showflat&Number=4821http://discussions.apple.com/thread.jspa?threadID=2118617https://iraf.net/phpBB2/viewtopic.php?t=87313&highlight=scisoft+freezeIf this is an old SciSoft install you might also try updating that, or try a new IRAF install from the binaries we distribute. Swapping disks may be a false solution, e.g. a slower disk may not trigger the same problem in a logic board. Hope this helps.-Mike