Chris, Also got it to crash using DRD and helgrind, here's the commandline that I used for each:
valgrind --tool=drd --read-var-info=yes valgrind --tool=helgrind The log file for each is up at: http://www.bluelavalamp.net/hugin/enfuse-openmp-segfault/ Thanks, Kevin On Thursday, November 29, 2012 10:52:10 AM UTC-5, cspiel wrote: > > Kevin - > > Am Mittwoch, 28. November 2012 20:45:29 UTC+1 schrieb kevin360: > > 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/ > > THX. I downloaded them. > > > > I then re-compiled adding in -g as you said and ran in gdb. > > Here's the output then itsegfaulted: > > (gdb) run > > Starting program: /usr/local/bin/enfuse-test 0.jpg 1.jpg -o > crash_small_test.tif > > ... > > 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) > > This is exactly what I was afraid of: > segfault out of the blue. However, our code, > which uses the Mersenne Twister RNG is tried and > true; the Boost RNG library supposedly is even > more mature. Thus, my conclusion is that the > multi-threading implementation in use wreaks > havoc to unrelated parts of your program. > > > > I did 20 runs of enfuse and got 8 segfaults. > > I enfused your image pair here on a > 4-way, 64-bit Debian-6.x box using three > different tool chains: > > $ g++ --version; clang++ --version; icpc --version > g++ (Debian 4.6.3-14) 4.6.3 > Copyright (C) 2011 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > clang version 3.2 (trunk 167223) > Target: x86_64-unknown-linux-gnu > Thread model: posix > > icpc (ICC) 13.0.1 20121010 > Copyright (C) 1985-2012 Intel Corporation. All rights reserved. > > with CXXFLAGS something like `-march=native -O2' > or `-xHost -O2'. > > Each binary run 25 times without any problems > and produced an expected output. (I checked the > latter only once per binary.) So, everything > looks fine here. > > Furthermore, neither Helgrind, nor DRD did find > any thread errors in Enfuse. They just chewed > up humongous amounts of CPU cycles. > > > /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
