|
From: Cheng L. <scr...@gm...> - 2015-02-11 02:58:17
|
Hi peter, Me too. If I compiled your adjoint branch with -O3 and then compiled your ad example with -O3 -std=c++11, the error raised up...(the same segmentation fault) However if I compiled ad example with only -std=c++11, then no error occurs. I don't know why... Regards, Cheng -----邮件原件----- 发件人: Peter Caspers [mailto:pca...@gm...] 发送时间: 2015年2月11日 3:58 收件人: QuantLib Mailing Lists 主题: [Quantlib-dev] segmentation fault in boost ? Hi, when compiling QL without -std=c++11, then an application (e.g. one of the examples) _with_ -std=c++11, I get the following weird error even before the first instruction in main was executed ==19902== Memcheck, a memory error detector ==19902== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19902== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info ==19902== Command: ./adjoint ==19902== ==19902== ==19902== Process terminating with default action of signal 11 (SIGSEGV) ==19902== Bad permissions for mapped region at address 0x4DC608 ==19902== at 0x540F054: long double boost::math::lanczos::lanczos17m64::lanczos_sum<long double>(long double const&) (in /home/peter/quantlib/QuantLib/ql/.libs/libQuantLib.so.0.0.0) ==19902== by 0x540F121: boost::math::lanczos::lanczos_initializer<boost::math::lanczos::lanczos17m64 , long double>::init::init() (lanczos.hpp:49) ==19902== by 0x5257E26: __static_initialization_and_destruction_0 (lanczos.hpp:64) ==19902== by 0x5257E26: _GLOBAL__sub_I_gaussianlhplossmodel.cpp (gaussianlhplossmodel.cpp:202) ==19902== by 0x400F855: call_init.part.0 (dl-init.c:84) ==19902== by 0x400F90F: call_init (dl-init.c:55) ==19902== by 0x400F90F: _dl_init (dl-init.c:133) ==19902== by 0x4001669: ??? (in /lib/x86_64-linux-gnu/ld-2.17.so) ==19902== ==19902== HEAP SUMMARY: ==19902== in use at exit: 4,316 bytes in 7 blocks ==19902== total heap usage: 8 allocs, 1 frees, 37,132 bytes allocated ==19902== ==19902== LEAK SUMMARY: ==19902== definitely lost: 0 bytes in 0 blocks ==19902== indirectly lost: 0 bytes in 0 blocks ==19902== possibly lost: 148 bytes in 2 blocks ==19902== still reachable: 4,168 bytes in 5 blocks ==19902== suppressed: 0 bytes in 0 blocks ==19902== Rerun with --leak-check=full to see details of leaked memory ==19902== ==19902== For counts of detected and suppressed errors, rerun with: -v ==19902== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Anyone observed this too ? Drove me crazy until I realized the pattern. What is behind ? The other way around (QL with c++11, example without) works fine. Produced with gcc 4.9.1, boost 1.57.0 under Ubuntu. Thanks Peter ---------------------------------------------------------------------------- -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list Qua...@li... https://lists.sourceforge.net/lists/listinfo/quantlib-dev |