strange bug
Ralf Stephan
ralf at ark.in-berlin.de
Thu Jul 15 15:18:01 CEST 2004
I've traced it to a point where stack corruption occurs; somewhere
in the printing line, operator= on the smart pointer is called, and
the chaos appears while executing 'delete p' in that function:
#0 __gnu_cxx::__exchange_and_add (__mem=0x100176f0, __val=-1)
at atomicity.cc:55
#1 0x0ff43880 in ~symbol (this=0x10017588) at basic_string.h:215
#2 0x0ff09098 in std::_List_base<GiNaC::ex, std::allocator<GiNaC::ex> >::_M_clear (this=0x10017588) at ptr.h:78
#3 0x0ff090e0 in ~container (this=0x100177e8) at stl_list.h:328
#4 0x10002aec in GiNaC::ptr<GiNaC::basic>::operator= (this=0x40001,
other=@0x11) at ptr.h:86
#5 0x1000281c in GiNaC::ex::operator= (this=0x10013238, _ctor_arg=@0x10017858)
at matrix.h:107
#6 0x100021ec in main () at bug3.cpp:13
Note the func arguments in frame 4. Note also that they were intact when
starting the destructor. Finally, this is not the point where the main
ex is overwritten causing segv but earlier.
I cannot rule out a libstdc++ bug in the (newly installed) version
of g++ 3.4. Can you test that?
ralf
More information about the GiNaC-devel
mailing list