segmentation fault when stitching
Cristian Marchi
(version 0.8.0.3563) on my ubuntu Intrepid 64 bit and tried it.
All went well until I press the "stitch now!" button. Here is the output
I get
nona -z PACKBITS -r ldr -m TIFF_m -o neve -i 0 /tmp/huginpto_VVm2Mx
nona -z PACKBITS -r ldr -m TIFF_m -o neve -i 1 /tmp/huginpto_VVm2Mx
nona -z PACKBITS -r ldr -m TIFF_m -o neve -i 2 /tmp/huginpto_VVm2Mx
enblend --compression NONE -f5114x3948 -o neve.tif neve0000.tif
neve0001.tif neve0002.tif
Loading next image: neve0000.tif
Loading next image: neve0001.tif
Creating blend mask: 1/4 2/4 3/4 4/4
Optimizing 1 distinct seam.
Strategy 1, s0: 1/4 2/4 3/4 4/4
Strategy 2: s0
make: *** [neve.tif] Segmentation fault
make: *** Cancellazione di `neve.tif'
Then I get a warning that ask to report the problem on sourceforge.
I tried different images and different paths but I always get this message.
What could be the problem?
Thanks
Cristian
Alex Romosan
> I hope this is the right place to ask but tonight I've built Hugin
> (version 0.8.0.3563) on my ubuntu Intrepid 64 bit and tried it.
>
> All went well until I press the "stitch now!" button. Here is the output
> I get
>
> nona -z PACKBITS -r ldr -m TIFF_m -o neve -i 0 /tmp/huginpto_VVm2Mx
> nona -z PACKBITS -r ldr -m TIFF_m -o neve -i 1 /tmp/huginpto_VVm2Mx
> nona -z PACKBITS -r ldr -m TIFF_m -o neve -i 2 /tmp/huginpto_VVm2Mx
> enblend --compression NONE -f5114x3948 -o neve.tif neve0000.tif
> neve0001.tif neve0002.tif
> Loading next image: neve0000.tif
> Loading next image: neve0001.tif
> Creating blend mask: 1/4 2/4 3/4 4/4
> Optimizing 1 distinct seam.
> Strategy 1, s0: 1/4 2/4 3/4 4/4
> Strategy 2: s0
> make: *** [neve.tif] Segmentation fault
> make: *** Cancellazione di `neve.tif'
recompile enblend with debugging turned on and the problem will go
away. for some people compiling with -O2 instead of -O3 also worked
but i haven't tried it yet.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
cri
adding '--enable-debug=yes' to the command './configure'. If so it
didn't work.
Thanks for the answer
Alex Romosan
> Sorry for the noob question but for debugging turned on you mean
> adding '--enable-debug=yes' to the command './configure'. If so it
> didn't work.
that should do it. did you do a make clean before running configure,
and then install the new executable? just making sure...
cri
You did right by making sure! that was exactly what was needed. ;-)
Thanks for the help
Cristian
jovada
error seems to occur on 64 bit only, Mac OS X in my case.
Thanks,
Joris
Lukáš Jirkovský
sebastien delcoigne
I also have this problem on my AMD 64bit and ubuntu studio. It only occurs for me, if I try to change the default name of the output or if I try to change the default path it proposes. If I leave hugin create the files where it wants it works fine.
Sébastien
Joris Van Dael
sebastien delcoigne
Sébastien
Joris Van Dael
The error I got in the standard version has now changed to the following (in the latest Mac OS build):
(is the only solution still compiling enblend myself?)
Loading next image: p0061.tif
Strategy 2:
enblend: Seam s1 is a tiny closed contour and was removed after optimization.
s0 s1gnumake: *** [p.tif] Bus error
gnumake: *** Deleting file `p.tif'
>----- Oorspronkelijk bericht -----
>Van
: sebastien delcoigne [mailto:sebastien...@gmail.com]
>Verzonden
: donderdag
, december
11, 2008 10:00 AM
>Aan
: hugi...@googlegroups.com
>Onderwerp
: [hugin-ptx] Re: segmentation fault when stitching
jovada
Loading next image: architectural0090.tif
Optimizing 2 distinct seams.
Strategy 1, s0: 1/4 2/4 3/4 4/4
Strategy 1, s1:
Strategy 2:
enblend: Seam s1 is a tiny closed contour and was removed after
optimization.
gnumake: *** Deleting file `architectural.tif'
This happened while processing ..90.tif, the previous time it was ..
29.tif, so it happens at different stages...
To get my images finally stitched, I tried the ImageFuser software.
(The latest version which was posted a couple of days ago) This also
crashed and in an even earlier stage:
ImageFuser, while opening the set of images:
AppleScript Error
Can’t make current application into type anything. (-1700)
Does anyone have an idea how I can make a panorama?? :)
When I got to know Hugin, it was a pretty early version and slow as
hell... To get my Gigapans stitched I had to wait a couple of days,
but it worked... Always. Now I haven't published anything in months,
since everything keeps on crashing... I do have respect for all the
volunteers that contribute to this possibly wonderful piece of
software, but it never seems to work for me...
On 11 dec 2008, 10:59, "Joris Van Dael" <jov...@telenet.be> wrote:
> I'm sorry, but I'd posted this newerrormessage in the wrong thread:
>
> (is the only solution still compiling enblend myself?)
>
> Loading next image: p0061.tif
> Creating blend mask: 1/4 2/4 3/4 4/4
> Optimizing 2 distinct seams.
> Strategy 1, s0: 1/4 2/4 3/4 4/4
> Strategy 1, s1:
> Strategy 2:
> enblend: Seam s1 is a tiny closed contour and was removed after optimization.
> s0 s1gnumake: *** [p.tif]Buserror
> gnumake: *** Deleting file `p.tif'
>
> >----- Oorspronkelijk bericht -----
> >Van
>
> : donderdag
> , december
> 11, 2008 10:00 AM>Aan
>
> : hugi...@googlegroups.com>Onderwerp
>
> : [hugin-ptx] Re: segmentation fault when stitching
>
>
>
> >Exactely, the tiff file. The default name is composed with the names of the
> >input pictures (name_of_the_first_picture-name_of_the_last_picture.tif)
>
> >On Wed, Dec 10, 2008 at 9:10 PM, Joris Van Dael <jov...@telenet.be> wrote:
>
> >> What do you mean by the output? The TIFF file for instance? In Mac OS,
> >> there's no default suggestion, so I have to type one myself...
>
> >> Op 10-dec-08, om 10:37 heeft sebastien delcoigne het volgende geschreven:
>
> >> Hi everyone,
>
> >> I also have this problem on my AMD 64bit and ubuntu studio. It only occurs
> >> for me, if I try to change the default name of the output or if I try to
> >> change the default path it proposes. If I leave hugin create the files where
> >> it wants it works fine.
>
>
> >>> 2008/12/9 jovada <jov...@telenet.be>:
>
> >>> > Is there also a solution that doesn't involve recompiling? :) This
Harry van der Wolf
I keep on getting this "Bus error":
Loading next image: architectural0090.tif
Creating blend mask: 1/4 2/4 3/4 4/4s0 s1gnumake: *** [architectural.tif] Bus error
Optimizing 2 distinct seams.
Strategy 1, s0: 1/4 2/4 3/4 4/4
Strategy 1, s1:
Strategy 2:
enblend: Seam s1 is a tiny closed contour and was removed after
optimization.
gnumake: *** Deleting file `architectural.tif'
This happened while processing ..90.tif, the previous time it was ..
Which version of Hugin did you use? Which hardware are you on (G3, G4, G5, Intel) and which osx version do you use.
29.tif, so it happens at different stages...
To get my images finally stitched, I tried the ImageFuser software.
(The latest version which was posted a couple of days ago) This also
crashed and in an even earlier stage:
ImageFuser, while opening the set of images:
AppleScript Error
Can't make current application into type anything. (-1700)
ImageFuser can't create panorama's. It's used to "enfuse" images. However, the application shouldn't crash. Can you tell me what you did to make it crash?
Does anyone have an idea how I can make a panorama?? :)
When I got to know Hugin, it was a pretty early version and slow as
hell... To get my Gigapans stitched I had to wait a couple of days,
but it worked... Always. Now I haven't published anything in months,
since everything keeps on crashing... I do have respect for all the
volunteers that contribute to this possibly wonderful piece of
software, but it never seems to work for me...
> TheerrorI got in the standard version has now changed to the following (in the latest Mac OS build):
On 11 dec 2008, 10:59, "Joris Van Dael" <jov...@telenet.be> wrote:
> I'm sorry, but I'd posted this newerrormessage in the wrong thread:
>
>
> (is the only solution still compiling enblend myself?)
>
> Loading next image: p0061.tif
> Creating blend mask: 1/4 2/4 3/4 4/4
> Optimizing 2 distinct seams.
> Strategy 1, s0: 1/4 2/4 3/4 4/4
> Strategy 1, s1:
> Strategy 2:
> enblend: Seam s1 is a tiny closed contour and was removed after optimization.
> s0 s1gnumake: *** [p.tif]Buserror
> gnumake: *** Deleting file `p.tif'
>
Try with enblend setting "--fine-mask" in your enblend preferences
Harry
Joris Van Dael
Joris Van Dael
Harry van der Wolf
237 jpgs, 774 MB is a huge amount of data. Did you already try to increase buffer memory to say 350-500 Megs (Hugin->preferences->General). With 4 Gb internal memory you can do this easily.
If it works: OK. If it now crashs in a later stadium you might even increase it to a higher number.
Please give it a try.
Harry
ImageFuser, which is compiled Applescript, can't handle that at all due to internal restrictions..
Joris Van Dael
Seb Perez-D
500 MB didn't work, so I thought I'd try 2,000 MB. Alas... Any other ideas?Thanks,JorisLoading next image: architectural0111.tifCreating blend mask: 1/4 2/4 3/4 4/4Optimizing 2 distinct seams.Strategy 1, s0: 1/4 2/4 3/4 4/4Strategy 1, s1:enblend: Seam s1 is a tiny closed contour and was removed after optimization.Strategy 2: s0 s1gnumake: *** [architectural.tif] Bus errorgnumake: *** Deleting file `architectural.tif'
Cheers,
Seb
Joris Van Dael
Everytime I try, it's another image that triggers the crash. The "tiny closed contour" thing happens with other images too... I'll try again tonight and I bet it will crash again at yet another .tif...
J.
>----- Oorspronkelijk bericht -----
>Van
: Seb Perez-D [mailto:sbprz...@gmail.com]
>Verzonden
: donderdag
, januari
8, 2009 08:37 AM
>Aan
: hugi...@googlegroups.com
>Onderwerp
: [hugin-ptx] Re: segmentation fault when stitching
>
paul womack
At the risk of sounding old-fashioned, can the command be run
under a debugger, or the core dump analysed after the fact, to give
a stack trace of the error?
BugBear
Rich
> Seb Perez-D wrote:
>> On Thu, Jan 8, 2009 at 08:17, Joris Van Dael <jov...@telenet.be
>> <mailto:jov...@telenet.be>> wrote:
>>
>> 500 MB didn't work, so I thought I'd try 2,000 MB. Alas... Any
>> other ideas?
>> Thanks,
>> Joris
>>
>> Loading next image: architectural0111.tif
>> Creating blend mask: 1/4 2/4 3/4 4/4
>> Optimizing 2 distinct seams.
>> Strategy 1, s0: 1/4 2/4 3/4 4/4
>> Strategy 1, s1:
>>
>> enblend: Seam s1 is a tiny closed contour and was removed after
>> optimization.
>> Strategy 2: s0 s1gnumake: *** [architectural.tif] Bus error
>> gnumake: *** Deleting file `architectural.tif'
i missed most of the thread, but have you tried running enblend manually
from the commandline ?
that gnu make "bus error" looks weird
>> This seems to be a problem with enblend - not hugin. I am surprised by
>> the "Seam s1 is a tiny closed contour" which makes me think this is a
>> particular image. What happens if you remove the 0111 image ?
>
>
> At the risk of sounding old-fashioned, can the command be run
> under a debugger, or the core dump analysed after the fact, to give
> a stack trace of the error?
>
> BugBear
--
Rich
David Brodsky
I've got this problem too.
This is caused by this particular code in createMask in enblend:
for (Segment::iterator currentVertex = snake->begin(); ; ) {
Segment::iterator nextVertex = currentVertex;
++nextVertex;
if (nextVertex == snake->end()) nextVertex = snake->begin();
if (currentVertex->first || nextVertex->first) {
// Find shortest path between these points
Point2D currentPoint = currentVertex->second;
Point2D nextPoint = nextVertex->second;
where snake->empty() is true (because of the optimization). The code is
located below comment
// Use Dijkstra to route between moveable snake vertices over mismatchImage.
So snake is empty, nextVertex is preincremented so that it doesn't
equals to snake->end() anymore and
Point2D nextPoint = nextVertex->second;
causes some nasty things. Byt maybe I'm wrong.
I've solved this problem by putting
if (snake->empty())
continue;
just after the initialization of snake variable, so the whole part now
looks like
// Use Dijkstra to route between moveable snake vertices over
// mismatchImage.
segmentNumber = 0;
for (ContourVector::iterator currentContour = contours.begin();
currentContour != contours.end();
++currentContour) {
for (Contour::iterator currentSegment = (*currentContour)->begin();
currentSegment != (*currentContour)->end();
++currentSegment) {
Segment *snake = *currentSegment;
if (snake->empty())
continue;
if (Verbose > VERBOSE_MASK_MESSAGES) {
cout << " s" << segmentNumber++;
cout.flush();
}
for (Segment::iterator currentVertex = snake->begin(); ; ) {
Segment::iterator nextVertex = currentVertex;
++nextVertex;
if (nextVertex == snake->end()) nextVertex = snake->begin();
and it enblend doesn't crash anymore with that particular error. Also I
cannot find any error in the output, so maybe it is the correct
solution.
Regards,
David Brodsky
P.S. I couldn't post line number beacause of my other changes in the
source code like debugging messages etc.
Andrew Mihal
Thanks for finding this bug. I've added your patch to CVS.
Andrew
Alex Romosan
> This is caused by this particular code in createMask in enblend:
>
> for (Segment::iterator currentVertex = snake->begin(); ; ) {
> Segment::iterator nextVertex = currentVertex;
> ++nextVertex;
> if (nextVertex == snake->end()) nextVertex = snake->begin();
>
> if (currentVertex->first || nextVertex->first) {
> // Find shortest path between these points
> Point2D currentPoint = currentVertex->second;
> Point2D nextPoint = nextVertex->second;
>
> where snake->empty() is true (because of the optimization). The code is
> located below comment
i still get a core dump even with this patch applied. the only way i
can get enblend to work is to compile it with debugging symbols (it
was also suggested that compiling with -O2 instead of -O3 might also
work but i haven't tried it).
Andrew Mihal
This is a different bug, which I have not been able to reproduce.
Even valgrind did not catch anything, although I think I only tried
this with debugging symbols turned on. I could try it again with O3.
If anyone can produce a stack trace of this crash it would help.
Thanks,
Andrew
Lukáš Jirkovský
it's GCC bug. Everything in code seems fine. Now I'm playing with
Valgrind if I can find the bug with it.
paul womack
> David Brodsky writes:
>
>> This is caused by this particular code in createMask in enblend:
>>
>> for (Segment::iterator currentVertex = snake->begin(); ; ) {
>> Segment::iterator nextVertex = currentVertex;
>> ++nextVertex;
>> if (nextVertex == snake->end()) nextVertex = snake->begin();
>>
>> if (currentVertex->first || nextVertex->first) {
>> // Find shortest path between these points
>> Point2D currentPoint = currentVertex->second;
>> Point2D nextPoint = nextVertex->second;
>>
>> where snake->empty() is true (because of the optimization). The code is
>> located below comment
>
> i still get a core dump even with this patch applied. the only way i
> can get enblend to work is to compile it with debugging symbols (it
> was also suggested that compiling with -O2 instead of -O3 might also
> work but i haven't tried it).
Damn - that implies the "true" fault is stack overrun.
As I've said before:
>
> In which case, I was going to recommend "hoping" for a dev
> to have access to rational Purify, which paid for itself
> (at a previous company) by finding a single bug which we'd
> spent 20 man days trying to track.
>
> However, I'm out of date, and Linux has Valgrind, which is free!
>
> http://funwithlinux.blogspot.com/2007/02/detecting-memory-leaks-in-gnulinux.html
>
> BugBear
Lukáš Jirkovský
working (maybe -O1 would also work). If you want it optimized you
should use gcc 3.x.
I've been working to get rid of this bug a lot, but as I've said it's
more likely GCC (maybe someone should try my test images with windows
and/or mac version) because code is obviously without errors (and
there aren't any strange values, it just segfaults).
Bruno Postle
>
>Anyway, compiling with -O2 doesn't help, you have to use -O0 to get it
>working (maybe -O1 would also work). If you want it optimized you
>should use gcc 3.x.
This bug (#2121647 in the hugin tracker) doesn't seem to appear with
the fedora enblend package. The only difference I can see is the
custom fedora build flags:
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
--
Bruno
Lukáš Jirkovský
Thanks for hint, I'll try these flags, maybe some of them will make it
work. Anyway, which version of gcc is used for compiling fedora
package?
Harry van der Wolf
For what it's worth.
On MacOSX enblend functions correctly too (as fas as I know). As we need to cross-compile on Mac for both ppc and intel and when building on Leopard with extra settings to also make it function on Tiger, we need to use a huge load of CFLAGS, CXXFLAGS, LDFLAGS and configure settings to make that work. Mentioning all these MacOSX specific settings (not even including specific ppc/intel tuning parameters) is not usefull here.
Specifics I would want to mention are:
- use of C/CXX-FLAGS "-ftree-vectorize", "-D_THREAD_SAFE" and "-Wall"
- compile with -O2 optimization
In the configure step: --disable-dependency-tracking --enable-image-cache=yes
And we have to manually set HAVE_MALLOC to 1 in the config.h as the AC_FUNC_MALLOC doesn't function correctly (only on MacOSX??)
@Lucas: On Tiger gcc 3.3 is used to compile ppc binaries/libraries and gcc 4.0 to compile intel binaries/libraries.
On Leopard both gcc 4.0.1 and 4.2.1 are available to compile both intel and ppc, where 4.0.1 is the default (I don't know why and didn't to comparison tests yet).
Harry
Alex Romosan
it's not the optimization level (-O2) it's the debugging symbols (-g).
try compiling it without -g and i am sure it will seg fault as well.
with -O3 and -g i get enblend to work on debian just fine.
Lukáš Jirkovský
I've tried compiling enblend with gcc 4.2.4 and it seems that enblend
works correctly. It's probably problem only with gcc 4.3.x
Alex Romosan
> I've tried compiling enblend with gcc 4.2.4 and it seems that
> enblend works correctly. It's probably problem only with gcc 4.3.x
not for me. i tried compiling it with 4.2.4 on debian and i got a
segmentation fault. running it under valgrind gives:
Invalid read of size 1
at 0x518B09: void enblend::maskBounds<vigra::CachedFileImage<unsigned char> >(vigra::CachedFileImage<unsigned char>*, vigra::Rect2D&, vigra::Rect2D&) (in /usr/local/bin/enblend)
by 0x672DB3: void enblend::enblendMain<vigra::RGBValue<unsigned char, 0, 1, 2> >(std::list<vigra::ImageImportInfo*, std::allocator<vigra::ImageImportInfo*> >&, vigra::ImageExportInfo&, vigra::Rect2D&) (in /usr/local/bin/enblend)
by 0x40944F: main (in /usr/local/bin/enblend)
Address 0x1 is not stack'd, malloc'd or (recently) free'd
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x1
at 0x518B09: void enblend::maskBounds<vigra::CachedFileImage<unsigned char> >(vigra::CachedFileImage<unsigned char>*, vigra::Rect2D&, vigra::Rect2D&) (in /usr/local/bin/enblend)
by 0x672DB3: void enblend::enblendMain<vigra::RGBValue<unsigned char, 0, 1, 2> >(std::list<vigra::ImageImportInfo*, std::allocator<vigra::ImageImportInfo*> >&, vigra::ImageExportInfo&, vigra::Rect2D&) (in /usr/local/bin/enblend)
by 0x40944F: main (in /usr/local/bin/enblend)
are you sure you didn't compile enblend with debugging symbols on (-g)?
Lukáš Jirkovský
I've compiled it with --enable-debug=no, but maybe it turned some
debug symbols, I'll try it later. But anyway, with gcc 4.3 it
segfaults even with debugging symbols turned on.
Alex Romosan
> I've compiled it with --enable-debug=no, but maybe it turned some
> debug symbols, I'll try it later. But anyway, with gcc 4.3 it
> segfaults even with debugging symbols turned on.
not for me. compiling with --enable-debug=yes works with both gcc
4.2.4 and gcc 4.3.2 (which is the default in debian unstable). btw,
are you doing a make clean between reconfigures (and compilations)?
Andrew Mihal
This gives me an idea. The loop in maskBounds tries to maintain
two pointers into the same image that point at different rows, my and
myPrev. I suspect that the image cache is not guaranteeing that both
rows are in memory simultaneously. Before the SKIPSM-based pyramid
algorithms came out, there used to be a swap policy that kept the last
few accessed rows in memory so that the 5x5 filter windows would not
thrash. This policy has since been changed with the expectation that
only one row needs to be accessed at a time. I forgot about this loop
in maskBounds when making that swap policy change. I suggest adding
assertions to the CachedFileImageIteratorBase to check that currentRow
is non-null before dereferencing it.
This bug also appeared at about the time I was making changes to
CachedFileImageIteratorBase::_notify and setNotify. The code in
maskBounds makes use of lots of iterator copy constructors and
assignment operators. It may be the case that somewhere in there the
notification process gets messed up and an iterator ends up without a
valid currentRow. The idea is that each iterator points to an actual
row of data in the image cache via the currentRow member, which is
updated whenever the iterator changes it's Y coordinate. This is meant
to minimize the number of cache queries that are done.
Thanks for putting time into this bug. It's a tough one.
Andrew
Andrew Mihal
One thing to add - you might want to use the -x option for Enblend
to turn on checkpointing of partial results. This tells Enblend to
save the results after each blend step, so if it does crash after the
100th image, you aren't left with nothing. This is off by default
because it slows down the process. You can then resume by running
Enblend again using the partial result as an input along with the
unprocessed images. Then if this reproduces the crash, send in a bug
report.
Andrew
DaveN
Yousendit.com can handle files up to 2 GB. You can upload a zip of
the images and post the link here.
Lukáš Jirkovský
>
> Hi,
> This gives me an idea. The loop in maskBounds tries to maintain
> two pointers into the same image that point at different rows, my and
> myPrev. I suspect that the image cache is not guaranteeing that both
> rows are in memory simultaneously. Before the SKIPSM-based pyramid
> algorithms came out, there used to be a swap policy that kept the last
> few accessed rows in memory so that the 5x5 filter windows would not
> thrash. This policy has since been changed with the expectation that
> only one row needs to be accessed at a time. I forgot about this loop
> in maskBounds when making that swap policy change. I suggest adding
> assertions to the CachedFileImageIteratorBase to check that currentRow
> is non-null before dereferencing it.
I'm not much experienced, but shouldn't it be a problem only if mx and
mxLeft were stored in a CPU register?
Joris Van Dael
thanks, but as I've posted two days ago, my problem is solved since
the new Enblend version came out :) No more errors for me!
J.
Op 11-jan-09, om 06:25 heeft DaveN het volgende geschreven:
Lukáš Jirkovský
Regards
Lukas "stativ" Jirkovsky
Joris Van Dael
segmentation fault... I know that it became another error in the end,
but still, it's solved :)
Op 11-jan-09, om 16:18 heeft Lukáš Jirkovský het volgende geschreven:
Lukáš Jirkovský
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38625) and the cause was
found. I'm attaching small patch to configure.in against newest cvs
which adds necessary flag to CXXFLAGS when compiler is GCC.
Can someone test it? It's still a little bit hackish, but it works for me.
Regards
Lukas "stativ" Jirkovsky
Kornel Benko
Yes, but it works. I tried some projects, and it did not crash.
Very "nice" bug indeed.
Kornel
--
Kornel Benko
Kornel...@berlin.de
Alex Romosan
adding --param inline-unit-growth=60 to g++ compile flags makes
enblend work fine without debugging symbols. thanks for finding this.
Felix Hagemann
Works for me. A test case that was segfaulting reproducibly when
compiling without debugging symbols now completes. And four to fives
times faster as well, finallz making pano stitching and blending fun
again!
Thanks for sorting this out,
Felix
Lukáš Jirkovský
compiler (often reffered as icc). Main reason was to prove that this
segmentation fault is GCC-only problem. Moreover intel's compiler is
the most picky compiler I know.
The other reason was to try if enblend will be faster (actually it's
slower) when compiled with icc.
And result? It really seems that segmentation fault is problem only
with GCC 4.3.* because it doesn't occur with any other compiler and
the code seems right. So even my patch could look like an ugly hack it
is probably proper solution to this bug. I hope that it'll get to the
trunk.
Anyway if I change the problematic code to something like this:
for (int x = 1; mx.x < mend.x; ++x, ++mx.x, ++mxLeft.x, ++mxUp.x) {
(*mxLeft != *mx);
std::cout << "something #0\n";
int foo = (*mxLeft != *mx);
std::cout << "something #1: foo = " << foo << "\n";
mBB |= Rect2D(x - 1, y, x + 1, y + 1);
std::cout << "something #2\n";
if (*mxLeft != *mx) mBB |= Rect2D(x - 1, y, x + 1, y + 1);
if (*mxUp != *mx) mBB |= Rect2D(x, y - 1, x + 1, y + 1);
}
enblend prints:
Creating blend mask: 1/4 2/4 3/4 4/4
Optimizing 1 distinct seam.
Strategy 1, s0: 1/4 2/4 3/4 4/4
Strategy 2: s0
something #0
Segmentation fault
So it clearly shows, that problem is really in (*mxLeft != *mx); The
first use doesn't use returned value, so it's probably missing in
generated code. But in the second use, where it's returned value is
stored in variable, it segfaults. If I comment this part out mBB |=
Rect2D(x - 1, y, x + 1, y + 1); is performed corectly.