[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KToolBar problem
From:       Reginald Stadlbauer <reggie () trolltech ! com>
Date:       2000-10-07 10:46:27
[Download RAW message or body]

On Sat, 07 Oct 2000, David Faure wrote:
> On Fri, 06 Oct 2000, Reginald Stadlbauer wrote :
> >On Fri, 06 Oct 2000, Michael Reiher wrote:
> >> > Hi
> >>
> >> There is some evil problem in KToolBar which leads to weird crashes in
> >> Konqueror in certain cases when you manipulate your boorkmarks. The most
> >> relieable way is probably deleting a bunch of bookmarks at once.
> >>
> >> The problem is that KToolBar keeps a second list of widgets which is
> >> read during rebuildLayout() and if there are illegal pointers in it ->
> >> crash. Widgets are removed from that list either explicitly or by a
> >> ChildRemove event. So normally when you delete a widget it gets cleand
> >> out by the event. However if you delete it so quickly that the
> >> ChildInserted event dosnīt get posted QObject simply deletes the
> >> Remove(and the Inserted) event. So KToolBar doesnīt get notifyed about
> >> the remove. And this is the case when modifying bookmarks. KBookmarkBar
> >> runs slotBookmarksChanged() which rebuilds the bookmarkbar. There is
> >> some kind of placeholder widget or whatever which gets simply deleted.
> >> KBookmarkbar doesnīt get the Removed event and keeps it -> crash on next
> >> layout.
> >>
> >> Iīm kinda unsure what to do now. Possible solutions:
> >> 1. Remove the placeholder widget. Doesnīt seem to serve any useful
> >> purpose anyway.
> >> 2. Explicitly remove it when clearing KBookmarkBar
> >> But these two are actually cheating and donīt fix the real Problem;-)
> >>
> >> 3. Implement some mechanism which compares KToolBars "widgets" list with
> >> the children() list and throw out illegal pointers. Though this one
> >> would have to be put in *every* place which accesses the widget list.
> >> Hmm...
> >>
> >> IMO all three are sub optimal. With regard to the current freeze Iīd go
> >> for 1. or 2. as they are the least dangerous. Attached a patch for 2.
> >>
> >> Any comments, please? Has anyone a better idea? Perhaps someone with
> >> more insight into
> >> KToolBar?
> >
> >Ok, following patch in KToolBar fixes the problem for me. Could be done
> >cleaner with using QGuarderPtr<QWidget> in the list and maps instead of
> >QWidget, but I think this wouldn't be binary compatible. So please review
> > and test this one:
>
> [...]
>
> Looks very good to me.
> Currently testing it.
>
> BTW an unrelated problem in KToolbar, as detected by Insure++ :
>
> [ktoolbar.cpp:1297] **FREE_DANGLING**
>
> >>     delete layout();
>
>   Freeing dangling pointer: layout()
>
>   Pointer : 0x0816c230
>   In block: 0x00000002 thru 0x00000000 (-1 bytes)
>                    freed at .psrc, 0
>
>   Stack trace where the error occurred:
>          KToolBar::rebuildLayout()  ktoolbar.cpp, 1297
>              KToolBar::showEvent()  ktoolbar.cpp, 1371
>                   QWidget::event()
>                  QToolBar::event()
>                  KToolBar::event()  ktoolbar.cpp, 1674
>             QApplication::notify()
>             KApplication::notify()  kapp.cpp, 506
>                    QWidget::show()
>                   QToolBar::show()
>                   KToolBar::show()  ktoolbar.cpp, 1425
>                    QWidget::show()
>                QMainWindow::show()
> KonqMisc::createBrowserWindowFromProfile()  konq_misc.cc, 96
>                             main()  konq_main.cc, 88
>
> **Memory corrupted.  Program may crash!!**

I have to look at it closer, but I don't believe that :-) QWidget::layout() 
gets 0 ASA it is deleted from somewhere (look at the QLayout dtor to convince 
yourself). So in theory this can't be a dangling pointer.

> I love this last statement :-)
>
> Also, the QBoxLayout built there is leaked according to insure++, but I'm
> quite surprised (it's given "this" as parent, so it's not a leak AFAICS).
> Really strange, because all other cases of something being build with a
> parent doesn't make insure believe there's a leak.......
>
> [ktoolbar.cpp:1331] **LEAK_SCOPE**
>
> >> }
>
>   Memory leaked leaving scope: bl
>
>   Lost block : 0x0816abc0 thru 0x0816ac17 (88 bytes, 1 element)
>                bl, allocated at:
>          KToolBar::rebuildLayout()  ktoolbar.cpp, 1298
>              KToolBar::showEvent()  ktoolbar.cpp, 1371
>                   QWidget::event()
>                  QToolBar::event()
>                  KToolBar::event()  ktoolbar.cpp, 1674
>             QApplication::notify()
>             KApplication::notify()  kapp.cpp, 506
>                    QWidget::show()
>
>   Stack trace where the error occurred:
>          KToolBar::rebuildLayout()  ktoolbar.cpp, 1331
>              KToolBar::showEvent()  ktoolbar.cpp, 1371
>                   QWidget::event()
>                  QToolBar::event()
>                  KToolBar::event()  ktoolbar.cpp, 1674
>             QApplication::notify()
>             KApplication::notify()  kapp.cpp, 506
>                    QWidget::show()
>                   QToolBar::show()
>                   KToolBar::show()  ktoolbar.cpp, 1425
>                    QWidget::show()
>                QMainWindow::show()
> KonqMisc::createBrowserWindowFromProfile()  konq_misc.cc, 96
>                             main()  konq_main.cc, 88

I do not belive that one as well....

-- 
Reggie (reggie@trolltech.com)

[prev in list] [next in list] [prev in thread] [next in thread]