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