iraf.net

I've just installed stsdas and tables under 2.15a using the nifty new method. It seems to have installed okay. Some things (like catfits in tables) work fine. But when I go to use histogram on a text file that works fine on an older installation, I get a segmentation error. Same thing happens if I change the input file.stsdas> histogram test2.dat
ERROR: segmentation violation
called as: `histogram (input=test2.dat)'
ERROR: segmentation violation
called as: `histogram (input=test2.dat)'lpar histogram input = "test2.dat" Input table or image or text file
(colname = "1") Name of column to use if input is table
(nbins = 3) Number of histogram bins
(z1 = INDEF) Minimum bin value
(z2 = INDEF) Maximum bin value
(listout = no) Print histogram?
(title = "Histogram: ") Title for plot
(xlabel = "Data values") Title for x axis
(ylabel = "Count") Title for y xaxis
(logplot = yes) Plot histogram with log y axis
(fulline = yes) Draw histogram lines to base of plot?
(cumulative = no) Calculate cumulative histogram?
(dvpar = "") Device parameters pset"
(Version = "2Feb96") Date of installation
(mode = "al")stsdas> type test2.dat
80
614
60
840
155
130
50
18
40
178
62
535
182
300
150
80
58
400
270

Hi Phil,I can reproduce the error on a Mac system (works fine on linux), however we only distribute whatever binaries are produced by STScI and they would need to fix the problem in the next release. You can contact their helpdesk at help@stsci.edu, in the meantime you get a similar result using the core PHISTOGRAM task, e.g.[code:1:c61285a94b]cl> phist test2.dat nbins=3 plot="box"[/code:1:c61285a94b]

OK, I learned something---I've been using histogram for many years, never knew about phistoram! THANKS.I'll email the STSCI help desk, and we'll see what happens.

It works for me in IRAF 2.14. I tried it in IRAF 2.15.1a, but I only have that available on a linux machine, so it is not surprising that it works. I see the problem when using Pyraf, but that is my only clue so far.If anybody else is seeing this problem, write to help@stsci.edu and mention that it is related to ticket 1249.Thanks,Mark S.

I find that if I setenv IRAFARCH macosxbefore I start CL, I have no problems. This causes it to run the 32 bit CL. Most users won't notice the difference between the 32/64 bit system.The fact that this fix works suggests to me that this is probably a bug in the handling of the pipe between CL and the tasks. We found some of these when IRAF 2.15 was still in alpha, but maybe there are still more.b.t.w. The STScI statement about 64 bit IRAF is available at http://www.stsci.edu/resources/software_hardware/stsdas/iraf64

[quote:08d93572a8]The fact that this fix works suggests to me that this is probably a bug in the handling of the pipe between CL and the tasks. We found some of these when IRAF 2.15 was still in alpha, but maybe there are still more.[/quote:08d93572a8]Gee, it woulda been great if somebody had told me about these .....With this clue I can confirm the message is coming from the CL not the task binary. Will fix it for the next release.

[quote:cc61c8dce0="fitz"]
Gee, it woulda been great if somebody had told me about these .....
[/quote:cc61c8dce0]
I did. You sent me patched binaries that worked. The protocol doesn't look very complicated, so I thought we found them all.I have a couple of open tickets around this problem. They all have to do with graphics. When you run a regular task, there is just text being passed in the packets in the pipe. I wonder if graphics use a binary format, so there is a level 2 binary protocol that might still have a bug relating to the size of some data item. This histogram crash was because of a floating point exception of some kind, which is consistent with my hypothesis. That's as far as I got with this problem, though.

But weren't those related to PyRAF graphics? This is the first I remember hearing about problems with 'pipes' or the CL?

The problem was that the metacode stream was being written to stdgraph with a control packet header containing a 32-bit descriptor number (because the HISTOGRAM task is still a 32-bit binary), but was being read in the 64-bit CL as a 64-bit integer, corrupting the stream and creating an invalid descriptor. This has now been fixed for the next release but you can get a patched ECL binary fromftp://iraf.noao.edu/iraf/v215/support/macintel/ecl.e
ftp://iraf.noao.edu/iraf/v215/support/linux64/ecl.eThe fix was to explicitly write the descriptor number as a 32-bit integer in order to be backwards compatible. For PyRAF graphics that might use the GKI directly, note that the descriptor number is still (in the current 64-bit binaries) being written as an 8-byte value. If it hasn't caused a problem so far you probably don't need to worry about it. Anyway, HISTOGRAM now works as expected.

Thanks!

Hi, Mike---It's true that "histogram" in stsdas now works with the new ecl.e. But other things don't. For instance, I loaded imred and kpnoslit and did an splot dev$pix
with the following result:kpnoslit> splot dev$pix
Image line/aperture to plot (0 (5): PANIC in `/iraf/iraf/bin.macintel/ecl.e': Salloc underflowPANIC in `/iraf/iraf/noao/bin.macintel/x_onedspec.e': Write to IPC with no reader[tig:~] massey%

I should have been more explicit: The patched ECL was linked against the graphics library that now uses an explicit 32-bit descriptor value, so when used with older 32-bit binaries it can be read. When the entire system is similarly linked with the patched graphics then even on a 64-bit system the descriptor is written as 32-bits, HOWEVER when using the patched ECL with current 64-bit binaries tasks like SPLOT still write a 64-bit value but the patched CL is expecting to read a 32-bit value. Resetting the IRAFARCH to 'macosx' will force the use of the 32-bit binaries (if they're installed), but to fix your entire system you'll need a new libsys.a and libex.a and a relink. If you want to do this I can send you the instructions.

Hi, Mike---I think it makes sense to wait until this is all straightened out, presumably in the next release. In the meanwhile I'll just go back to using the older 64-bit IRAF which "mostly" works. Or would you recommend installing the 32-bit IRAF
and just let it go at that for now?thanks,
phil

That's your call, do you need to use the 32-bit STSDAS graphics stuff more than you want to run a 64-bit system? You can install the combined OSX distribution (iraf-macosx.tar.gz) and then switch as needed by simply changing IRAFARCH.

Okay, this is what I didn't understand, that the problem is just restricted to the STSDAS routines that call graphics. Eassy call then. thanks!