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