[GiNaC-list] Crash Ginsh when trying to solve equation involving integral numerically

[Alexei Sheplyakov]

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