Ok, I shrunk the images down so they are smaller in byte size, but they are still fairly large in dimension. You can download the two of them here:
http://www.bluelavalamp.net/hugin/enfuse-openmp-segfault/ I did 20 runs of enfuse and got 8 segfaults. I then re-compiled adding in -g as you said and ran in gdb. Here's the output then it segfaulted: (gdb) run Starting program: /usr/local/bin/enfuse-test 0.jpg 1.jpg -o crash_small_test.tif warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". enfuse: info: input image "0.jpg" does not have an alpha channel; enfuse: info: assuming all pixels should contribute to the final image enfuse: info: input image "1.jpg" does not have an alpha channel; enfuse: info: assuming all pixels should contribute to the final image enfuse: warning: no usable resolution found in first image "0.jpg"; enfuse: warning: will use 300 dpi enfuse: info: loading next image: 0.jpg 1/1 [New Thread 0x7fffcb88c700 (LWP 2233)] [New Thread 0x7fffcb08b700 (LWP 2235)] [New Thread 0x7fffca88a700 (LWP 2237)] enfuse: info: loading next image: 1.jpg 1/1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffca88a700 (LWP 2237)] operator() (this=0x89cc00 <Twister>) at /usr/include/boost/random/mersenne_twister.hpp:454 454 UIntType z = x[i]; (gdb) Hope this helps! Kevin On Wednesday, November 28, 2012 10:59:19 AM UTC-5, cspiel wrote: > > Kevin - > > Am Mittwoch, 28. November 2012 12:54:03 UTC+1 schrieb kevin360: > > I reduced the number of input images to 2 and it still segfaults. > > Nice job! Two is perfect for testing. > If the images aren't too large, do you think it > makes sense to supply them to us? I'd like to > reproduce your findings on my system. > > > > Next I reduced the image size which caused the segfaults to go away. > > I increased the size and it came back. I'm using images that are > > 9,000 pixels on the long side right now. Doing 40 runs with 2 of > > those images it segfaulted 12 times. Turning off openmp from the > > shell (OMP_NUM_THREADS=1) and it completes every run. > > The OMP_NUM_THREADS=1 test proves that > either the OpenMP synchronization is faulty or > at least one thread tramples on another one's > memory. None of which I have ever heard before > for Enfuse code as its OpenMP code is > extraordinarily simple. > > > > Next I tried to compile in the debug support but that crashes the > > compile. Just to be sure I re-ran configure and just removed the > > --enable-debug, compiles fine. Run configure again putting back in > > --enable-debug, make clean, make and it crashes. Here's the command > > where it crashes: > > Doh, I should have been more specific. > I meant: ensure that the "-g" option is passed > to the compiler _and_ the linker when I said > "compile with debug support". This makes > backtraces much easier to read. > > Whether you configure with or without debug > support, i.e. `--enable-debug' or > `--disable-debug' should not matter. > > > One more idea: If you have a suitable > "libgomp.so" (i.e. configured with > `--disable-linux-futex') at hand, you can run > Enfuse under the supervision of Helgrind (after > preloading the correct "libgomp.so"). No idea, > whether this will unveil the cause of the > problem, though. > > > HTH, > Chris > > -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
