Re: [Quantlib-dev] 答复: segmentation fault in boost ?

[Peter C. <pca...@gm...>]

yes. It's not specific to the adjoint branch, but a more general
problem, actually I found this related post in the meantime

http://comments.gmane.org/gmane.comp.compilers.clang.devel/36032

so it seems to be a boost feature / bug.

best
Peter


On 11 February 2015 at 03:55, Cheng Li <scr...@gm...> wrote:
> 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
>