Crashes on closing applications

[Raphael Kubo da Costa]

On Sunday 11 July 2010 15:04:58 Rolf Eike Beer wrote:
> Raphael Kubo da Costa wrote:
> > On Sunday 11 July 2010 11:25:39 Rolf Eike Beer wrote:
> > > Thomas Lübking wrote:
> > > > Am Sunday 11 July 2010 schrieb Rolf Eike Beer:
> > > > > I just wonder why this is libstdc++-v3, openSuSE 11.2 uses gcc 4.4
> > > > > by default?
> > > > 
> > > > I don't think the libstdc++ version ever changed since gcc3 (and
> > > > indeed, it's -v3 on gcc 4.5 as well)
> > > > 
> > > > The whole thing looks quite like a memory ("0x6" ...) corruption, but
> > > > testing
> > > > 
> > > > gcc -O[n] std_string_seg.cpp -lstdc++ -o std_string_seg | n = 0-3
> > > > 
> > > > on the -plain std::string, no KDE- attachment doesn't fail at all
> > > > (i however don't know how -optimized- my libstdc++ was compiled)
> > > > 
> > > > So this is either in the particular OpenSuSE libstdc++ or an overflow
> > > > in some KDE lib.
> > > > 
> > > > I also attached a binary, compiled and linked on arch, 32bit x86,
> > > > gcc4.5 prerelease, -O2, lisbstdc++.so.6.0.14 - maybe test it with gdb
> > > 
> > > It's not that trivial, otherwise I think it would have been long
> > > solved. For example if you start dolphin and immediately close it
> > > afterwards the crash does not happen. If you do some work before
> > > closing it it will crash.
> > > 
> > > I also suspect not the string object itself be the problem, but the
> > > memory within that (i.e. the string data). We see those crashes with
> > > all string objects being on the stack as I suspect the report from
> > > that google search does too.
> > > 
> > > And once again: "delete 0" is fine but must return immediately. In the
> > > backtrace it doesn't but tries to dereference something. Although I
> > > find that offset 0x6 suspicious, I would have expected a multiple of 4
> > > for any offsets holding a pointer.
> > > 
> > > Eike
> > 
> > Does Valgrind say anything useful in this case?
> 
> I'm not absolutely sure if I triggered this as I didn't see DrKonqi, but
> this looks suspiciuos:
> 
> Invalid free() / delete / delete[]
>    at 0x40265BD: operator delete(void*) (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
>    by 0x5EB399A: std::string::_Rep::_M_destroy(std::allocator<char> const&)
> (in /usr/lib/libstdc++.so.6.0.12)
>    by 0x5EB5459: std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.12)
>    by 0x412F49A: __cxa_finalize (in /lib/libc-2.10.1.so)
>    by 0x67F2273: ??? (in /usr/lib/libstreams.so.0.7.2)
>    by 0x6819F9F: ??? (in /usr/lib/libstreams.so.0.7.2)
>    by 0x400EE15: ??? (in /lib/ld-2.10.1.so)
>    by 0x412F110: ??? (in /lib/libc-2.10.1.so)
>    by 0x412F16C: exit (in /lib/libc-2.10.1.so)
>    by 0x4117AD5: (below main) (in /lib/libc-2.10.1.so)
>  Address 0x7828458 is 0 bytes inside a block of size 18 free'd
>    at 0x40265BD: operator delete(void*) (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
>    by 0x5EB399A: std::string::_Rep::_M_destroy(std::allocator<char> const&)
> (in /usr/lib/libstdc++.so.6.0.12)
>    by 0x5EB5459: std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.12)
>    by 0x412F110: ??? (in /lib/libc-2.10.1.so)
>    by 0x412F16C: exit (in /lib/libc-2.10.1.so)
>    by 0x4117AD5: (below main) (in /lib/libc-2.10.1.so)

Can you install the packages with the missing debug symbols and check again? 
By the way, libstreams comes from strigi, so that may provide a clue.