On Tue, Aug 17, 2010 at 01:49:19PM +0200, Joerg Arndt wrote:
Valgrind may be of help:
% valgrind --leak-check=full --show-reachable=yes ginsh ==5369== Memcheck, a memory error detector ==5369== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==5369== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==5369== Command: ginsh ==5369== ginsh - GiNaC Interactive Shell (ginac V1.5.8) __, _______ Copyright (C) 1999-2010 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'.
Type ?? for a list of help topics.
fsolve((1/(sqrt(2*Pi)))*integral(t,0,x,exp(-1/2*t^2))==0.5,x,0,100) ==5369== Invalid read of size 4 ==5369== at 0x4F64D60: GiNaC::fsolve(GiNaC::ex const&, GiNaC::symbol const&, GiNaC::numeric const&, GiNaC::numeric const&) (object.h:211) ==5369== by 0x4118B7: f_fsolve(GiNaC::container<std::vector> const&) (ginsh_parser.yy:442) ==5369== by 0x416B6C: yyparse() (ginsh_parser.yy:256) ==5369== by 0x417C0F: main (ginsh_parser.yy:960) ==5369== Address 0x7064b90 is 0 bytes inside a block of size 16 free'd ==5369== at 0x4C25C8D: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5369== by 0x4EC9064: GiNaC::add::~add() (new_allocator.h:95) ==5369== by 0x4F63D85: GiNaC::fsolve(GiNaC::ex const&, GiNaC::symbol const&, GiNaC::numeric const&, GiNaC::numeric const&) (ex.h:66) ==5369== by 0x4118B7: f_fsolve(GiNaC::container<std::vector> const&) (ginsh_parser.yy:442) ==5369== by 0x416B6C: yyparse() (ginsh_parser.yy:256) ==5369== by 0x417C0F: main (ginsh_parser.yy:960) ==5369== ==5369== Invalid write of size 4 ==5369== at 0x4F64D67: GiNaC::fsolve(GiNaC::ex const&, GiNaC::symbol const&, GiNaC::numeric const&, GiNaC::numeric const&) (object.h:211) ==5369== by 0x4118B7: f_fsolve(GiNaC::container<std::vector> const&) (ginsh_parser.yy:442) ==5369== by 0x416B6C: yyparse() (ginsh_parser.yy:256) ==5369== by 0x417C0F: main (ginsh_parser.yy:960) ==5369== Address 0x7064b90 is 0 bytes inside a block of size 16 free'd ==5369== at 0x4C25C8D: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5369== by 0x4EC9064: GiNaC::add::~add() (new_allocator.h:95) ==5369== by 0x4F63D85: GiNaC::fsolve(GiNaC::ex const&, GiNaC::symbol const&, GiNaC::numeric const&, GiNaC::numeric const&) (ex.h:66) ==5369== by 0x4118B7: f_fsolve(GiNaC::container<std::vector> const&) (ginsh_parser.yy:442) ==5369== by 0x416B6C: yyparse() (ginsh_parser.yy:256) ==5369== by 0x417C0F: main (ginsh_parser.yy:960) ==5369==
This looks like a double free/delete. It might be the cause of memory corruption reported by glibc. Still I don't quite understand what's going on. Perhaps our wrapped (a.k.a. "smart") pointers are not that smart, and got the reference counting wrong in some corner case(s). Or refcount get corrupted even earlier (due to some different bug).
Note no segfault happens.
I guess valgrind detects the double delete attempt and does not actually delete the dead object. Best regards, Alexei