2.15a : able to run old binaries?
Mark S. wrote on Mar 08, 2010
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.
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.
Mike Fitzpatrick wrote on Mar 08, 2010
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
% /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. wrote on Mar 08, 2010
That helped. Now it says
I'm going to try to debug that, but already it leads to my first suggested patch:
In unix/os/zpanic.c in the function ZPANIC, it says:
The definition of debug_sig is in unix/os/zxwhen.c, but it is just
There are no other assignments anywhere. If I were making the change, I would change ZPANIC to say
so that I could flip between normal operation and allowing the core dump without compiling the entire IRAF kernel.
I suspect there is a better place to put it (like maybe in some initialization code somwehere), but I am not familiar enough with IRAF internals to know where it should go.
I realize the implications, of course: My old executable compiled with the old iraf would not have that capability. Still, I think this is a useful feature going forward.
Mark S.
stsdas> iminfo dev$pix
PANIC in `/usr/stsci/iraf-2.15a/stsdas/bin.linux64/x_headers.e': Memory has been corrupted
stsdas>
I'm going to try to debug that, but already it leads to my first suggested patch:
In unix/os/zpanic.c in the function ZPANIC, it says:
/* Terminate process with a core dump if the debug_sig flag is set.
*/
if (debug_sig) {
#ifdef LINUX
signal (SIGABRT, SIG_DFL);
kill (getpid(), SIGABRT);
The definition of debug_sig is in unix/os/zxwhen.c, but it is just
int debug_sig = 0;
There are no other assignments anywhere. If I were making the change, I would change ZPANIC to say
if (debug_sig || getenv("IRAF_ALLOW_CORE_DUMP") ) {
so that I could flip between normal operation and allowing the core dump without compiling the entire IRAF kernel.
I suspect there is a better place to put it (like maybe in some initialization code somwehere), but I am not familiar enough with IRAF internals to know where it should go.
I realize the implications, of course: My old executable compiled with the old iraf would not have that capability. Still, I think this is a useful feature going forward.
Mark S.
Mike Fitzpatrick wrote on Mar 08, 2010
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
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
Last post on Mar 08, 2010