Serious kdecore problems

[Lubos Lunak]

On Friday 03 of October 2003 10:10, George Staikos wrote:
>   For weeks now, perhaps much longer, there have been some serious problems
> in CVS-HEAD.  I think they are related to kdecore, but I'm not entirely
> sure because the problem is very hard to track down.  The symptoms are
> clear, and are seen by many people.  I've seen it on 4 different systems
> myself (different compilers, OS releases, etc too).  We have had multiple
> reports of this on bugs.kde.org.  I have spent many hours trying to
> reproduce this, trying to catch it in valgrind or gdb in a useful manner,
> trying to diagnose it, and trying to fix it.  I definitely haven't solved
> the problem yet, though I do have a patch that makes it harder to
> reproduce.
>
>    The problem:
>
>    Changing widget styles, among other things, causes weird random crashes
> in konqueror or kicker (at least) that always have a similar backtrace.

 Cannot reproduce ... not that surprising, lately it looks like I cannot 
reproduce anything :-/

> Sometimes the crash will just happen for no apparent reason, such as moving
> the mouse across the screen and having it run overtop of a konqueror
> window.

 Since this is icons related, it's very likely that the mouseover causes new 
loading of an icon (e.g. the active state), which hasn't been loaded yet, 
because of delayed loading.

> The crashes most often have this in the backtrace:
>
> #6 0x40e006f6 in QString::QString(QString const&) ()
> #7 0x406f9e87 in KIconEffect::fingerprint(int, int) const (this=0x82da7fc,
> group=-1073749796, state=0)
> #8 0x40708c2e in KIconLoader::loadIcon(QString const&, KIcon::Group, int,
> int, QString*, bool) const (this=0x82d0f58, _name=@0x8418d84, group=Small,
> size=137257888, state=0, path_store=0x0, canReturnNull=false)
>
>    Note the size in #8 is bogus, the group in #7 is bogus.  A group like
> that will certainly cause a crash.  It shouldn't be able to get that far
> though.
>
>    I have seen other similar backtraces, especially when I try to remove
> the static objects (see below for more details):
> #3 in _static_initialization_and_destruction_0
> ....
> #6 in KIconLoader::loadIcon(...) with QString _name=@0x1 (!!!),
> state=18979792 (!!!), canReturnNull=65, size=1, etc
>
> Also one with:
> #4 KIconLoader::init() with _dirs=0x3bf0 (nice pointer)
>
>    Investigations led me to believe that there were corrupt static objects.
> GDB would show null references all over the place and they all pointed to
> what should have been static memory.  If I remove all static objects from
> KIconLoader, it becomes much more difficult to reproduce the problem but it
> still happens.  The backtrace is different, and looks quite bogus now
> (KIconLoader::init->KIconTheme->KLocale::readMoney->QString->crash->KGlobal
>AccelPrivate::activate) Null references and bad pointers are all over the
> place in the backtrace.
>
>    I tried to trigger this in valgrind.  It's very difficult to do this for
> some reason.  Tonight I triggered it for the first time.  Valgrind crashed
> when it happened.  I'm going to try again.  Here is what I managed to get
> before it crashed:
[two long backtraces]

>
> Meanwhile what else am I trying?  I read through cvs history and noticed a
> change that could remotely be an influence in some way.  In kinstance.cpp
> near line 200 delayed iconset loading was enabled in the not-too-distant
> past.  I tried disabling this and I have been completely unable to
> reproduce the crashes since.  Does anyone have some insight into this? 
> Carsten?  Of course I'm not declaring this to be the cause of the problems
> because they are so unpredictable, but normally I can trigger a crash
> fairly easily given this much time.  I'm getting suspicious that this is
> what triggered the start of these crashes.

 Hardly. That Carsten's change actually enabled delayed icon loading only in 
some cases, before this change it was always used. Based on your debug info, 
I was even considering the possibility of some bug in delayed icon loading, 
but now I doubt. There's no KIconFactory in the backtraces, and as it's 
dynamically created, I believe valgrind would find corruptions related to it.

 I don't actually see how valgrind can report invalid read of size 4 in 
KInstance::iconLoader(). It just reads a static variable, and returns it, 
there cannot be anything invalid about that. I'd find it strange even in case 
of _iconLoader == 0.

 Maybe you could add large blocks before and after the static vars and do 
VALGRIND_MAKE_NOACCESS() on them.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/