Posted: Wed Feb 15, 2006 8:28 pm Post subject: bug in imcombine
hi all... I guess this is the place to make a bug report?
I have found a problem in imcombine, I have been trying to track it down as I found it in a copy of the imcombine code (which I compiled to a library in order to use from another task). But the bug is in the original too and though I'd love to have more information it occurs to me I should report it before looking more because of course you're likely to understand it better.
imcombine seg faults for us when
AND NCOMBINE is different in each image.
Reject doesn't seem key but weight, combine and the NCOMBINE value in the header seem to be the crucial factors generating the seg fault.
#0 0x081608a7 in icaver_ ()
#1 0x08138620 in iccomr_ ()
#2 0x08137aa1 in icombr_ ()
#3 0x080ec4ed in icombe_ ()
#4 0x08082257 in timcoe_ ()
#5 0x0804ab78 in sysruk_ ()
#6 0x0827823b in irafmn_ ()
#7 0x081cb5bc in main ()
#8 0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
Basically it's dying in the averager when told not to average but do a sum, which is indicated with a flag.
Here is to hoping you turn this puzzle into a simple explanation. I'd appreciate information about how you've done any fix to imcombine so I can also change the version we use as a library.
I'm sure Frank will have a closer look at this once he has a moment, but on the assumption the stack trace may be bogus because of a memory corruption elsewhere. have a look at the suggestions made in
for using ElectricFence to trap errors sooner. I'm also assuming this is a linux system, if not the let us know. Is this a data-specific bug or do you see it with any two images with different NCOMBINE keywords? Is this within a script use or
can you reproduce it with a command-line call to IMCOMBINE just as easily? FITS images only or .imh fail as well??
Frank will of course have to verify the fix, but I was able to easily reproduce the problem. What appears to be happening is that in the ic_combine() routine a list of "image index pointers" is maintained (the 'id' pointer if you look at the code), however these are never actually set prior to the ic_average() call with the given combination of parameters. Specifically, the 'keepids' variable remains false.
Anyway, one workaround is to set the 'grow' parameter to some value greater than 1.0, but I believe the code change needed is to edit the case statement on line 229 of icomb.gx to read
case AVERAGE, SUM:
Most of this message is aimed at Frank but I assume it makes some sense to you as well. You'll need to figure out how this translates to your library code. Hope it helps.
I agree with the fix that Mike proposed. I filed the following bug log.
DATE: Tue Feb 28 14:07:30 MST 2006
BUG: When the combine option is sum and weighting is selected an exception
occurs. The sum option was added as a later feature and a
flag needed for weighting was not set. There is no workaround to
combine weighting and summing directly. One can use "average" and
the scale the result to the equivalent of a sum.
Posted: Wed Mar 01, 2006 6:47 pm Post subject: thanks
that definitely helped and was the cause of our segfault.
I guess I don't fully understand your comment Frank, "There is no workaround to
combine weighting and summing directly" but I can check it out more to see if it means what I'm guessing, which is that the weight won't be taken into account and the pixels will be directly summed...
in either case thanks greatly! what a pain this one was.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum