Posted by
cheng li on
Feb 11, 2015; 2:52am
URL: http://quantlib.414.s1.nabble.com/segmentation-fault-in-boost-tp16259p16262.html
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:
[hidden email]]
发送时间: 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev