imcombine segmentation violation error: IRAF v2.15, OSX 10.7
emma wrote on Aug 21, 2012
Hi Mike, Frank,
I'm currently working with user who is reporting a segmentation violation error when using imcombine from the 32-bit version of IRAF v2.15 on a Mac OSX 10.7.4. I have (as best as I can remotely) verified that the user's installation is good. The imcombine command was executed immediately after starting IRAF and initialising the uparm directory. The data do not contain any extremely large or extremely low values:
The following command should allow you to reproduce the problem:
If the user excludes any one of the files, the segmentation violation error disappears.
I don't have a Mac OSX 10.7 available to me, so it hasn't been possible for me to reproduced the error.
I have uploaded the files to ftp://iraf.noao.edu/pub/. Please let me know if you are able to reproduce the error. If you are unable to reproduce the error, please let me know if you have any further suggestions on how to fix the problem :)
Many thanks,
Emma :)
I'm currently working with user who is reporting a segmentation violation error when using imcombine from the 32-bit version of IRAF v2.15 on a Mac OSX 10.7.4. I have (as best as I can remotely) verified that the user's installation is good. The imcombine command was executed immediately after starting IRAF and initialising the uparm directory. The data do not contain any extremely large or extremely low values:
ecl> imstat file?.fits[SCI,1]
# IMAGE NPIX MEAN STDDEV MIN MAX
file1.fits[SCI,1] 7160832 7.435 332.8 -1007. 133625.
file2.fits[SCI,1] 7160832 6.84 315.8 -996.8 133626.
file3.fits[SCI,1] 7160832 6.399 306.7 -1009. 133629.
file4.fits[SCI,1] 7160832 5.677 308.3 -1005. 133630.
file5.fits[SCI,1] 7160832 5.229 326.5 -1008. 133627.
file6.fits[SCI,1] 7160832 4.794 308.7 -1002. 133628.
file7.fits[SCI,1] 7160832 4.497 332.2 -1013. 137116.
file8.fits[SCI,1] 7160832 4.349 307. -1005. 133630.
file9.fits[SCI,1] 7160832 4.382 307.2 -994.5 133629.
The following command should allow you to reproduce the problem:
ecl> imcombine file?.fits[SCI,1] output.fitsIf the user excludes any one of the files, the segmentation violation error disappears.
I don't have a Mac OSX 10.7 available to me, so it hasn't been possible for me to reproduced the error.
I have uploaded the files to ftp://iraf.noao.edu/pub/. Please let me know if you are able to reproduce the error. If you are unable to reproduce the error, please let me know if you have any further suggestions on how to fix the problem :)
Many thanks,
Emma :)
Mike Fitzpatrick wrote on Aug 21, 2012
I tried multiple IRAF versions and multiple architectures on both 10.6 and 10.7 systems but wasn't able to reproduce the problem.
Be sure this isn't a known bug such as the one below, is it possible one of your scripts is setting the 'grow' parameter or some other and so your example commandline using the default parameters wouldn't show the problem? If this is a scisoft release then the binaries might also pre-date the fix of this bug. Otherwise there are no known issues with the task that haven't been fixed and unfortunately not much we can do without reproducing the problem.
Be sure this isn't a known bug such as the one below, is it possible one of your scripts is setting the 'grow' parameter or some other and so your example commandline using the default parameters wouldn't show the problem? If this is a scisoft release then the binaries might also pre-date the fix of this bug. Otherwise there are no known issues with the task that haven't been fixed and unfortunately not much we can do without reproducing the problem.
emma wrote on Aug 21, 2012
Thank you for your reply, Mike :)
The grow parameter is set to the default of 0 ... the user was running imcombine directly on the data immediately after initialising the uparm directory, so there should be no problems with parameter settings. However, would it be possible for you to provide me with the date of the binary that contains the fix so I can double check with the user that they do have the latest version, please? (they are using scisoft)
Many thanks,
Emma :)
The grow parameter is set to the default of 0 ... the user was running imcombine directly on the data immediately after initialising the uparm directory, so there should be no problems with parameter settings. However, would it be possible for you to provide me with the date of the binary that contains the fix so I can double check with the user that they do have the latest version, please? (they are using scisoft)
Many thanks,
Emma :)
Mike Fitzpatrick wrote on Aug 21, 2012
The last v2.15.1 patch was 3/25/11 but the bug I forgot to post (#580) actually came after that and so is fixed in v2.16. However, using the v2.15.1 binaries I wasn't able to reproduce it either
NUMBER: 580
MODULE: imcombine and variants
SYSTEM: -V2.15.1
DATE: Fri Apr 1 10:53:41 MST 2011
FROM: valdes
BUG: When the grow options is used with masks or partially overlapping
data a segmentation could occur. This is because when data is
absent (because of non-overlap) or excluded (because of mask) an
identifier value was not initialized. The only workaround is to
not use the grow options.
STATUS: Fixed for future patches and releases.
emma wrote on Aug 21, 2012
Aha! I managed to get access to a Mac OSX 10.7.4 and I have been able to reproduce the problem :) Using IRAF v2.15.1a:
I ran mkiraf, started iraf and ran imcombine:
I'm using the 32-bit binaries:
The grow parameter is definitely set to 0:
Is there anything I can do to help you debug this further?
Please let me know :)
Many thanks,
Emma :)
ecl> print (cl.version)
IRAF V2.15.1a Feb 2011
I ran mkiraf, started iraf and ran imcombine:
ecl> imcombine file?.fits[SCI,1] output.fits
Aug 22 18:32: IMCOMBINE
combine = average, scale = none, zero = none, weight = none
blank = 0.
Images
file1.fits[SCI,1]
file2.fits[SCI,1]
file3.fits[SCI,1]
file4.fits[SCI,1]
file5.fits[SCI,1]
file6.fits[SCI,1]
file7.fits[SCI,1]
file8.fits[SCI,1]
file9.fits[SCI,1]
Output image = output.fits, ncombine = 9
ERROR: segmentation violation
I'm using the 32-bit binaries:
ecl> show IRAFARCH
macosx
The grow parameter is definitely set to 0:
ecl> lpar imcombine
input = List of images to combine
output = List of output images
(headers = "") List of header files (optional)
(bpmasks = "") List of bad pixel masks (optional)
(rejmasks = "") List of rejection masks (optional)
(nrejmasks = "") List of number rejected masks (optional)
(expmasks = "") List of exposure masks (optional)
(sigmas = "") List of sigma images (optional)
(imcmb = "$I") Keyword for IMCMB keywords
(logfile = "STDOUT") Log file\n
(combine = "average") Type of combine operation
(reject = "none") Type of rejection
(project = no) Project highest dimension of input images?
(outtype = "real") Output image pixel datatype
(outlimits = "") Output limits (x1 x2 y1 y2 ...)
(offsets = "none") Input image offsets
(masktype = "none") Mask type
(maskvalue = "0") Mask value
(blank = 0.) Value if there are no pixels\n
(scale = "none") Image scaling
(zero = "none") Image zero point offset
(weight = "none") Image weights
(statsec = "") Image section for computing statistics
(expname = "") Image header exposure time keyword\n
(lthreshold = INDEF) Lower threshold
(hthreshold = INDEF) Upper threshold
(nlow = 1) minmax: Number of low pixels to reject
(nhigh = 1) minmax: Number of high pixels to reject
(nkeep = 1) Minimum to keep (pos) or maximum to reject (neg
(mclip = yes) Use median in sigma clipping algorithms?
(lsigma = 3.) Lower sigma clipping factor
(hsigma = 3.) Upper sigma clipping factor
(rdnoise = "0.") ccdclip: CCD readout noise (electrons)
(gain = "1.") ccdclip: CCD gain (electrons/DN)
(snoise = "0.") ccdclip: Sensitivity noise (fraction)
(sigscale = 0.1) Tolerance for sigma clipping scaling correction
(pclip = -0.5) pclip: Percentile clipping parameter
(grow = 0.) Radius (pixels) for neighbor rejection
(mode = "ql")
Is there anything I can do to help you debug this further?
Please let me know :)
Many thanks,
Emma :)
Mike Fitzpatrick wrote on Aug 21, 2012
Other than access to a machine that reproduces the problem, the only thing that might help is to run the task under a debugger to get a stack trace, i.e.
and send/post the stack trace.
Two things though: this will only help if it points to an obvious coding error, if this is a memory corruption where we need to debug this ourselves we back to needing a machine to reproduce the problem. Second, you should try the above using a v2.16 binary to see whether this is either a new bug or something possibly fixed already. In any case, a patch would likely require a new binary or IRAF update to fix unless you find a parameter setting that works around the problem.
cl> epar imcombine
..... set the parameters
cl> dpar imcombine > dpar
cl> logout
Then at the unix prompt
% gdb /iraf/iraf/bin.macosx/x_images.e
gdb> run imcombine @dpar
......if it then stops at the segfault
gdb> where
and send/post the stack trace.
Two things though: this will only help if it points to an obvious coding error, if this is a memory corruption where we need to debug this ourselves we back to needing a machine to reproduce the problem. Second, you should try the above using a v2.16 binary to see whether this is either a new bug or something possibly fixed already. In any case, a patch would likely require a new binary or IRAF update to fix unless you find a parameter setting that works around the problem.
emma wrote on Aug 21, 2012
Hi Mike,
Thanks for the info. Here's what I got:
I can reproduce the error on Mac OSX 10.6.8.
I can also reproduce the error using IRAF v2.16 on Mac OSX 10.6.8:
Many thanks,
Emma :)
Thanks for the info. Here's what I got:
% gdb /iraf/iraf/bin.macosx/x_images.e
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done
(gdb) run imcombine @dpar
Starting program: /iraf/iraf/bin.macosx/x_images.e imcombine @dpar
Reading symbols for shared libraries +........................ done
Sep 10 20:50: IMCOMBINE
combine = average, scale = none, zero = none, weight = none
blank = 0.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffffffc
0x0021f073 in iclog_ ()
(gdb) where
#0 0x0021f073 in iclog_ ()
#1 0x002291a5 in icscae_ ()
#2 0x001ee3a8 in iccomr_ ()
#3 0x001ee167 in icombr_ ()
#4 0x00225a35 in icombe_ ()
#5 0x000b6f6d in timcoe_ ()
#6 0x00002237 in sysruk_ ()
#7 0x0043323e in irafmn_ ()
#8 0x002dffcc in main ()
(gdb)
I can reproduce the error on Mac OSX 10.6.8.
I can also reproduce the error using IRAF v2.16 on Mac OSX 10.6.8:
ecl> print (cl.version)
IRAF V2.16 March 2012
% gdb /iraf/iraf/bin.macosx/x_images.e
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done
(gdb) run imcombine @dpar
Starting program: /iraf/iraf/bin.macosx/x_images.e imcombine @dpar
Reading symbols for shared libraries +. done
Sep 10 20:18: IMCOMBINE
combine = average, scale = none, zero = none, weight = none
blank = 0.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffffffc
0x0021d363 in iclog_ ()
(gdb) where
#0 0x0021d363 in iclog_ ()
#1 0x0022734e in icscae_ ()
#2 0x001ed995 in iccomr_ ()
#3 0x001ed76c in icombr_ ()
#4 0x00223c11 in icombe_ ()
#5 0x000b916b in timcoe_ ()
#6 0x00002961 in sysruk_ ()
#7 0x004437dd in irafmn_ ()
#8 0x002de3f1 in main ()
(gdb)
Many thanks,
Emma :)
Mike Fitzpatrick wrote on Aug 21, 2012
I can reproduce the problem, but only of I use "file*.fits" as the input list and not 'file*.fits[SCI,1]', i.e. if I try to combine the MEF files and not individual extensions. Using your original test command, it all still works file for me.....
emma wrote on Aug 21, 2012
Apologies, Mike (I really shouldn't work so late on my first day back in the office!).
Here what I get when I use [SCI,1]:
Apologies again, it does works fine on Mac OSX 10.6.8 ... the problem is only reproducible on 10.7.4.
Many thanks,
Emma :)
Here what I get when I use [SCI,1]:
(gdb) run imcombine @dpar
Starting program: /iraf/iraf/bin.macosx/x_images.e imcombine @dpar
Reading symbols for shared libraries +........................ done
Sep 11 13:08: IMCOMBINE
combine = average, scale = none, zero = none, weight = none
blank = 0.
Images
file1.fits[SCI,1]
file2.fits[SCI,1]
file3.fits[SCI,1]
file4.fits[SCI,1]
file5.fits[SCI,1]
file6.fits[SCI,1]
file7.fits[SCI,1]
file8.fits[SCI,1]
file9.fits[SCI,1]
Output image = output.fits, ncombine = 9
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0070c374
0x00327876 in fxfzrd_ ()
(gdb) where
#0 0x00327876 in fxfzrd_ ()
#1 0x0046bc27 in zcall4_ ()
#2 0x003d1b1f in areadb_ ()
#3 0x003d1618 in aread_ ()
#4 0x003d5f27 in ffilbf_ ()
#5 0x003d5b08 in ffault_ ()
#6 0x003d7a2b in filbuf_ ()
#7 0x003e5c55 in xfread_ ()
#8 0x00343391 in imrdpx_ ()
#9 0x0033af7d in imggsc_ ()
#10 0x0033bc4f in imgnln_ ()
#11 0x002f8a9e in imgnlr_ ()
#12 0x0021a20c in xtimgr_ ()
#13 0x001d2a93 in icgdar_ ()
#14 0x001ef747 in iccomr_ ()
#15 0x001ee167 in icombr_ ()
#16 0x00225a35 in icombe_ ()
#17 0x000b6f6d in timcoe_ ()
#18 0x00002237 in sysruk_ ()
#19 0x0043323e in irafmn_ ()
#20 0x002dffcc in main ()
(gdb)
Apologies again, it does works fine on Mac OSX 10.6.8 ... the problem is only reproducible on 10.7.4.
Many thanks,
Emma :)
emma wrote on Aug 21, 2012
Hi Mike,
I was wondering whether you had been able to reproduce this error?
Many thanks,
Emma :)
I was wondering whether you had been able to reproduce this error?
Many thanks,
Emma :)
Mike Fitzpatrick wrote on Aug 21, 2012
I can reproduce it, I just haven't had time to debug it yet. It appears to be a memory error, but whether it is a specific FITS kernel bug or something in the task itself isn't clear.
emma wrote on Aug 21, 2012
Great! I'm glad you have been able to reproduce the error ... thanks for letting me know :)
emma wrote on Aug 21, 2012
Hi Mike,
Were you able to find a solution to the imcombine issue?
Please let me know.
Many thanks,
Emma :)
Were you able to find a solution to the imcombine issue?
Please let me know.
Many thanks,
Emma :)
Mike Fitzpatrick wrote on Aug 21, 2012
Sorry, I've been traveling and swamped with other projects and haven't gotten to it yet since there seems to be no easy indication of the problem. It is on the list for the next update and when I return.
emma wrote on Aug 21, 2012
Great! Thanks for the update :)
emma wrote on Aug 21, 2012
Hi Mike,
I recently received a second report of the segmentation violation error from imcombine. The second user is using IRAF v2.15 and Mac OS X 10.7.5. They were also able to reproduce the problem using the files I sent to you. However, they confirmed that the problem is not present when using IRAF v2.16 and Mac OS X 10.7.5. I'm sure I saw the problem using IRAF v2.16 and Mac OS X 10.7.4 ... but the Mac OS X 10.7.4 that I was using for testing was recently automatically upgraded to Mac OS X 10.7.5 and I can confirm that the problem is not present when using IRAF v2.16 and Mac OS X 10.7.5. When you said you were able to reproduce the problem, were you using IRAF v2.16 on Mac OS X 10.7.4?
Many thanks,
Emma :)
I recently received a second report of the segmentation violation error from imcombine. The second user is using IRAF v2.15 and Mac OS X 10.7.5. They were also able to reproduce the problem using the files I sent to you. However, they confirmed that the problem is not present when using IRAF v2.16 and Mac OS X 10.7.5. I'm sure I saw the problem using IRAF v2.16 and Mac OS X 10.7.4 ... but the Mac OS X 10.7.4 that I was using for testing was recently automatically upgraded to Mac OS X 10.7.5 and I can confirm that the problem is not present when using IRAF v2.16 and Mac OS X 10.7.5. When you said you were able to reproduce the problem, were you using IRAF v2.16 on Mac OS X 10.7.4?
Many thanks,
Emma :)
emma wrote on Aug 21, 2012
Hi Mike,
I just wanted to follow up with this imcombine issue ... were you able to resolve the problem?
Many thanks,
Emma :)
I just wanted to follow up with this imcombine issue ... were you able to resolve the problem?
Many thanks,
Emma :)
Last post on Aug 21, 2012