64-bit apall gives memory fwa corrupted panic error
Paul Kerry wrote on Feb 20, 2012
Hi
One of our users has come across a problem when using certain parameters within noao.twodspec.apextract.apall on 64-bit linux.
When running...
apall WUma-010.fit weights=variance pfit=fit2d
at the subsequent
"Review extracted spectra from WUma-10? (yes):"
prompt an error occurs if entering yes or no...
PANIC in `/irafr/iraf/noao/bin.linux64/x_apextract.e' : Memory fwa has been corrupted
doing exactly the same thing with the same file on 32-bit linux correctly shows the extracted spectrum.
Cheers
Paul.
One of our users has come across a problem when using certain parameters within noao.twodspec.apextract.apall on 64-bit linux.
When running...
apall WUma-010.fit weights=variance pfit=fit2d
at the subsequent
"Review extracted spectra from WUma-10? (yes):"
prompt an error occurs if entering yes or no...
PANIC in `/irafr/iraf/noao/bin.linux64/x_apextract.e' : Memory fwa has been corrupted
doing exactly the same thing with the same file on 32-bit linux correctly shows the extracted spectrum.
Cheers
Paul.
Paul Kerry wrote on Feb 20, 2012
sorry - forget to mention that this is using version 2.15.1a
Cheers
Paul
Cheers
Paul
Mike Fitzpatrick wrote on Feb 20, 2012
Paul,
There are no known issues with APALL and no recent changes to indicate something was fixed, so we'll need more information in order to be able to reproduce the problem. Could you upload the data files used as well as the parameter setting (e.g. "dpar apall") to the anonftp at ftp://iraf.noao.edu/pub so we can have a look?
-Mike
There are no known issues with APALL and no recent changes to indicate something was fixed, so we'll need more information in order to be able to reproduce the problem. Could you upload the data files used as well as the parameter setting (e.g. "dpar apall") to the anonftp at ftp://iraf.noao.edu/pub so we can have a look?
-Mike
Paul Kerry wrote on Feb 20, 2012
done...
data file: WUma-010.fit
parameters file: pkerry_apall_params.txt
Cheers
Paul.
data file: WUma-010.fit
parameters file: pkerry_apall_params.txt
Cheers
Paul.
Mike Fitzpatrick wrote on Feb 20, 2012
I can reproduce the error, but only on 64-bit linux. It appears to be some sort of memory corruption:
Note that in the ap_marsh() call the value of 'dbuf' changes to 0x12 from the parent ap_profile procedure's value. I'll have to punt to Frank to take a look.
#0 0x00002b188fc0afb5 in *__GI_raise (sig=<value optimized out>)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00002b188fc0cbc3 in *__GI_abort () at abort.c:88
#2 0x00002b188fc4fd10 in malloc_printerr (action=2,
str=0x2b188fd11ae6 "free(): invalid pointer", ptr=0x6587) at malloc.c:5999
#3 0x00000000005403e4 in zmfree_ (buf=0x955568, status=0x955d88)
at zmfree.c:21
#4 0x0000000000516704 in xmfree_ (ptr=0xa2f3a8, dtype=0x8fb078) at mfree.x:126
#5 0x00000000005177d2 in sfree_ (oldsp=0x904808) at salloc.x:113
#6 0x000000000042477a in apmarh_ (im=0x3f000000, dbuf=0x12, nc=0x902fb0,
nl=0xffffffffffffffff, c1=0x903030, l1=0x8de750, spec=0x0, sbuf=0x903070,
svar=0x903090, reject=0x2b188f636f90, profie=0x4d368f4, nx=0x902fe0,
ny=0x902fb8, xs=0x4ceb800, ys=0x8de750, x1=0x4d052e4, x2=0x4d063fc)
at approfile.x:992
#7 0x000000000042193a in approe_ (im=0x902fc8, ap=0x902fc0, dbuf=0x903028,
nc=0x902fb0, nl=0x902fb8, c1=0x903030, l1=0x8de750, sbuf=0x903070,
svar=0x903090, profie=0x4d368f4, nx=0x902fe0, ny=0x902fb8, xs=0x4ceb800,
ys=0x8de750, asi=0x902ff0) at approfile.x:299
#8 0x000000000040f8fc in apextt_ (input=0x4cd855e, output=0x4cd8966,
format=0x4cd9176, profis=0x9bd2fc, aps=0x17, naps=0x9bd2f8)
at apextract.x:576
#9 0x0000000000408acb in apall_ (ltask=0x9bd2fe) at t_apall.x:757
#10 0x00000000004078cb in tapall_ () at t_apall.x:51
#11 0x0000000000407429 in sysruk_ (task=0x94e41e, cmd=0x94bfbe,
rukarf=0x94e408, rukint=0x94e468) at x_apextract.x:143
#12 0x000000000050f4cb in irafmn_ (acmd=0x4cc134e, ainchn=0x7fff321a8f00,
aoutcn=0x7fff321a8f08, aerrcn=0x7fff321a8f10, adrivr=0x7fff321a8f28,
adevte=0x7fff321a8f18, prtype=0x90a920, bkgfie=0x90a71e,
jobcoe=0x7fff321a8f20, sysruk=0x407120 <sysruk_>,
onenty=0x510858 <onenty_>) at main.x:311
#13 0x0000000000456d07 in main (argc=2, argv=0x7fff321a9138) at zmain.c:192
Note that in the ap_marsh() call the value of 'dbuf' changes to 0x12 from the parent ap_profile procedure's value. I'll have to punt to Frank to take a look.
Paul Kerry wrote on Feb 20, 2012
Thanks for looking at this for us - as I mentioned in the first post, it works perfectly under 32-bit linux: it's only under 64-bit linux that it has a problem...
Cheers
Paul.
Cheers
Paul.
Francisco Valdes wrote on Feb 20, 2012
Hi Paul,
I was able to reproduce this and track the source down. Below is the bug report. So it will be fixed in the next release. If you need something sooner let us know and we can provide a special patch to you.
Regards,
Frank Valdes
I was able to reproduce this and track the source down. Below is the bug report. So it will be fixed in the next release. If you need something sooner let us know and we can provide a special patch to you.
Regards,
Frank Valdes
NUMBER: 583
MODULE: apall,
SYSTEM: V2.15
DATE: Mon Mar 5 08:51:03 MST 2012
FROM: valdes
BUG: The optimal extraction for significantly tilted spectra, the Marsh
algorithm, has bug which manifests only under 64-bit architectures.
The symptom is a crash, usually a memory or segmentation panic.
The only workarounds are 1) go to an 32-bit system or 2) don't
use the optimal extraction option.
STATUS: Fixed for V2.16.
Paul Kerry wrote on Feb 20, 2012
Thanks for fixing this - yes we could do with a patch if one is available please...
Cheers
Paul.
Cheers
Paul.
Mike Fitzpatrick wrote on Feb 20, 2012
A patched linux64 binary for v2.15 is available from
ftp://iraf.noao.edu/iraf/v215/support/linux64/x_apextract.e
Let us know if you still have problems.
ftp://iraf.noao.edu/iraf/v215/support/linux64/x_apextract.e
Let us know if you still have problems.
Paul Kerry wrote on Feb 20, 2012
I've put in the patched version, but when using apall on the same file and setting the extraction weights to "variance", I now get...
PANIC in `/iraf/iraf/noao/bin.linux64/x_apextract.e': Salloc underflow
Cheers
Paul.
PANIC in `/iraf/iraf/noao/bin.linux64/x_apextract.e': Salloc underflow
Cheers
Paul.
Mike Fitzpatrick wrote on Feb 20, 2012
Paul,
Try getting the binary again, there was a code change that was overlooked that would explain the error. Sorry for the inconvenience.
-Mike
Try getting the binary again, there was a code change that was overlooked that would explain the error. Sorry for the inconvenience.
-Mike
Paul Kerry wrote on Feb 20, 2012
Thanks Mike - I've put in the new binary, but there is now another problem :-(
apextract> apall
List of input images: WUma-010.fit
Find apertures for WUma-010? (yes):
Number of apertures to be found automatically: 1
Resize apertures for WUma-010? (yes):
Edit apertures for WUma-010? (yes):
ERROR: segmentation violation
called as: `apall ()'
at which point the graphics window should appear and doesn't and then I get kicked back to the "apextract>" prompt. It doesn't seem to make any difference if I change any apall parameters or if I run from a clean directory.
Cheers
Paul.
apextract> apall
List of input images: WUma-010.fit
Find apertures for WUma-010? (yes):
Number of apertures to be found automatically: 1
Resize apertures for WUma-010? (yes):
Edit apertures for WUma-010? (yes):
ERROR: segmentation violation
called as: `apall ()'
at which point the graphics window should appear and doesn't and then I get kicked back to the "apextract>" prompt. It doesn't seem to make any difference if I change any apall parameters or if I run from a clean directory.
Cheers
Paul.
Francisco Valdes wrote on Feb 20, 2012
Hi Paul,
The fixes I made work on your data with linux64 in the various ways you indicate. So please get the file:
ftp://iraf.noao.edu/iraf/v215/support/linux64/x_apextract.eFV
and install it the usual place renaming it to the usual name (i.e. x_apextract.e). This binary is the one I built on a different linux64 platform and have not had a problem. Please let us know whether it works or not. If not, just to be sure, return the result of
to double check the binary that is actually being run.
Yours,
Frank Valdes
The fixes I made work on your data with linux64 in the various ways you indicate. So please get the file:
ftp://iraf.noao.edu/iraf/v215/support/linux64/x_apextract.eFV
and install it the usual place renaming it to the usual name (i.e. x_apextract.e). This binary is the one I built on a different linux64 platform and have not had a problem. Please let us know whether it works or not. If not, just to be sure, return the result of
cl> dir noaobin$x_apextract.e l+to double check the binary that is actually being run.
Yours,
Frank Valdes
Paul Kerry wrote on Feb 20, 2012
that works perfectly - thanks for the fix...
Paul.
Paul.
H.J. van Heerden wrote on Feb 20, 2012
Hi
I updated from V2.15 to V2.16 last week. Since then I get the same kind of error as described below for my x64 system. Sometimes the PANIC turns up, but mostly it only gives the segmentation violation. The few times that the PANIC protocol did show and displayed a back-trace, it seemed that it originates in x_images.e.... ....which seems right because sections is a subtask of images->imutil->sections.
Could you please have a look, because I use the sections task in a lot of in-house scripts.
Thank U
Regards
Pat
I updated from V2.15 to V2.16 last week. Since then I get the same kind of error as described below for my x64 system. Sometimes the PANIC turns up, but mostly it only gives the segmentation violation. The few times that the PANIC protocol did show and displayed a back-trace, it seemed that it originates in x_images.e.... ....which seems right because sections is a subtask of images->imutil->sections.
Could you please have a look, because I use the sections task in a lot of in-house scripts.
Thank U
Regards
Pat
Mike Fitzpatrick wrote on Feb 20, 2012
I'm a bit confused, is this a separate report about a problem using SECTIONS and not another APALL problem (which doesn't call 'sections' as a task)?
If so, could you post more details (e.g. an example that fails, linux or mac, etc) so we can reproduce the problem. One thing to try is to
This will disable the new template code, and if it fixes the problem will tell us more about what might be wrong (but we'll still need the examples).
If so, could you post more details (e.g. an example that fails, linux or mac, etc) so we can reproduce the problem. One thing to try is to
cl> reset use_new_imt = noThis will disable the new template code, and if it fixes the problem will tell us more about what might be wrong (but we'll still need the examples).
H.J. van Heerden wrote on Feb 20, 2012
Hi
It is a separate report, with the same symptoms, therefore I thought I could add it to this discussion. Resetting the use_new_imt worked.
Hope it helps with possible bug source. Do not know if it my system setup/installation or something more.
Thanx
Pat
It is a separate report, with the same symptoms, therefore I thought I could add it to this discussion. Resetting the use_new_imt worked.
Hope it helps with possible bug source. Do not know if it my system setup/installation or something more.
Thanx
Pat
H.J. van Heerden wrote on Feb 20, 2012
Hi
FYI - I just changed my loginuser.cl as follows:
Regards
Pat
FYI - I just changed my loginuser.cl as follows:
# Set user parameters
# Set default editor
set editor = "vi"
# Set image type
set imtype = "fits"
#Reset image template
reset use_new_imt = no
# Call ds9
!ds9 &
keep
Regards
Pat
Mike Fitzpatrick wrote on Feb 20, 2012
Hope it helps with possible bug source. Do not know if it my system setup/installation or something more.
Not so much. All I know is there may be some issue with SECTIONS, could you post a sample problem I can investigate? What platform (linux of mac) are you using?
H.J. van Heerden wrote on Feb 20, 2012
Hi
OK! I checked another one of our newly updated IRAF systems, and it works fine, so therefore I can assume that the problem with sections is due to a fault in the specific system, and not in the IRAF installation. Uses the same IRAF extraction and installation setup for all our installations.
Use Fedora 15.x86_64 throughout. The problematic system's Linux platform was recently upgraded, so there might be a missing or corrupt lib somewhere. But it now works with the fix provided. I will recheck after each update of the system, might be able to pick up which lib caused the upset. Will let you know if and when I find possible source.
Regards
Pat
OK! I checked another one of our newly updated IRAF systems, and it works fine, so therefore I can assume that the problem with sections is due to a fault in the specific system, and not in the IRAF installation. Uses the same IRAF extraction and installation setup for all our installations.
Use Fedora 15.x86_64 throughout. The problematic system's Linux platform was recently upgraded, so there might be a missing or corrupt lib somewhere. But it now works with the fix provided. I will recheck after each update of the system, might be able to pick up which lib caused the upset. Will let you know if and when I find possible source.
Regards
Pat
Last post on Feb 20, 2012