2.15a : able to run old binaries?

[Mark S.]

Should I expect IRAF 2.15 to be able to communicate with binaries compiled by IRAF 2.14 ?

When I try:

cl
stsdas
iminfo dev$pix

it looks like this:

stsdas> iminfo dev$pix
ERROR: Cannot open connected subprocess (./x_headers.e)
stsdas> dir stsdas$bin/x_headers.e
xb-rwr--- iraf 2104282 Mar 7 21:44 stsdas$bin/x_headers.e
stsdas>

but if I run the same task out of the same directory in iraf 2.14, it works. Is this related to a change in the communication protocol between iraf and the tasks?

Mark S.

[fitz]

A 'cannot open connected subprocess' means that either the binary isn't in the right place, or it cannot be executed for some reason. Verify there is an x_headers.e file in the stsdas$bin.linux64 directory and that it has execute permissions. (Note you may need to create a 'bin.linux64' symlink that points to the directory with the old binaries so this path can be resolved.) If so, try starting it from outside iraf, e.g.

% /iraf/extern/stsdas/bin.linux64/x_headers.e

You'll either see a host error message (e.g. a missing 32-bit shared library or incompatible version) that may explain things, or the '> ' prompt meaning it started okay (type 'bye' to quit).

The communication between processes hasn't actually changed per se, although with the change in the size of INT there may be something I overlooked. In this case though I think it's a simple problem in finding binaries in a bin.linux64 directory.

-Mike

[Mark S.]

That helped. Now it says

[fitz]

I dont' think this has anything to do with v2.15, using the STScI-supplied binary on a 64-bit machine fails with an "Out of memory" error for me. This basically just means the libc malloc() call either failed or more likely returned a 64-bit pointer value that was seen as a failed request. This is one of the known issues with 32-bit binaries on 64-bit systems so unless you trace it to something else I'm not sure there's much to debug here.

As for the core dump: Normally we'd set the 'debug_sig' in a debugger or else simply set a break in 'zpanic_' and get the stack trace then. It's easy enough to add a method to dump a core file, the reason we don't do it by default is that error recovery allows tasks to continue to run so more manual methods are better to trap the error. Thanks for the suggestion.

-Mike