Welcome to iraf.net Thursday, March 28 2024 @ 07:13 PM GMT


 Forum Index > Help Desk > General IRAF New Topic Post Reply
 imcombine segmentation violation error: IRAF v2.15, OSX 10.7
   
emma
 08/21/2012 06:05PM (Read 10341 times)  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
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:[code:1:3295bed827]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.
[/code:1:3295bed827]The following command should allow you to reproduce the problem:[code:1:3295bed827]ecl> imcombine file?.fits[SCI,1] output.fits[/code:1:3295bed827]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 SmileMany thanks,Emma Smile

 
Profile Email
 Quote
fitz
 08/21/2012 06:05PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
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.

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
Thank you for your reply, Mike SmileThe 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 [i:f71e39d75c]are[/i:f71e39d75c] using scisoft)Many thanks,Emma Smile

 
Profile Email
 Quote
fitz
 08/21/2012 06:05PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
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
[quote:efaa869d2e]
NUMBER: 580
MODULE: imcombine and variants
SYSTEM: -V2.15.1
DATE: Fri Apr 1 10:53:41 MST 2011
FROM: valdesBUG: 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.[/quote:efaa869d2e]

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
Aha! I managed to get access to a Mac OSX 10.7.4 and I have been able to reproduce the problem Smile Using IRAF v2.15.1a:[code:1:22b9572a00]ecl> print (cl.version)
IRAF V2.15.1a Feb 2011
[/code:1:22b9572a00]I ran mkiraf, started iraf and ran imcombine:[code:1:22b9572a00]ecl> imcombine file?.fits[SCI,1] output.fitsAug 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
[/code:1:22b9572a00]I'm using the 32-bit binaries:
[code:1:22b9572a00]ecl> show IRAFARCH
macosx
[/code:1:22b9572a00]The grow parameter is definitely set to 0:[code:1:22b9572a00]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")
[/code:1:22b9572a00]Is there anything I can do to help you debug this further?Please let me know SmileMany thanks,Emma Smile

 
Profile Email
 Quote
fitz
 08/21/2012 06:05PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
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.[code:1:fd3826b8cb]
cl> epar imcombine
..... set the parameters
cl> dpar imcombine > dpar
cl> logoutThen 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
[/code:1:fd3826b8cb] 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.

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
Hi Mike,Thanks for the info. Here's what I got:[code:1:6fb86baa3e]% 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 +........................ doneSep 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)
[/code:1:6fb86baa3e]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:[code:1:6fb86baa3e]ecl> print (cl.version)
IRAF V2.16 March 2012
[/code:1:6fb86baa3e][code:1:6fb86baa3e] % 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 +. doneSep 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)
[/code:1:6fb86baa3e]Many thanks,Emma Smile

 
Profile Email
 Quote
fitz
 08/21/2012 06:05PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
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.....

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
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]:[code:1:9a50657496](gdb) run imcombine @dpar
Starting program: /iraf/iraf/bin.macosx/x_images.e imcombine @dpar
Reading symbols for shared libraries +........................ doneSep 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 = 9Program 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)
[/code:1:9a50657496]Apologies again, it does works fine on Mac OSX 10.6.8 ... the problem is only reproducible on 10.7.4.Many thanks,Emma Smile

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
Hi Mike,I was wondering whether you had been able to reproduce this error?Many thanks,Emma Smile

 
Profile Email
 Quote
fitz
 08/21/2012 06:05PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
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.

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
Great! I'm glad you have been able to reproduce the error ... thanks for letting me know Smile

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
Hi Mike,Were you able to find a solution to the imcombine issue?Please let me know.Many thanks,Emma Smile

 
Profile Email
 Quote
fitz
 08/21/2012 06:05PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
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.

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
Great! Thanks for the update Smile

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
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 Smile

 
Profile Email
 Quote
emma
 08/21/2012 06:05PM  
++++-
Regular Member

Status: offline


Registered: 01/23/2006
Posts: 101
Hi Mike,I just wanted to follow up with this imcombine issue ... were you able to resolve the problem?Many thanks,Emma Smile

 
Profile Email
 Quote
   
Content generated in: 0.50 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login