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

List:       kde-devel
Subject:    Re: Konqueror segfaults
From:       Maks Orlovich <mo002j () mail ! rochester ! edu>
Date:       2002-10-06 20:03:30
[Download RAW message or body]

Till Krech wrote:

> On Sunday 06 October 2002 17:42, Maks Orlovich wrote:
>> Till Krech wrote:
>> > On Sunday 06 October 2002 16:04, Shu-yu Guo wrote:
>> >> Hello,
>> >>
>> >> Upon trying 3.1-beta2, konqueror crashes with a segfault upon exit.
>> >> So, I decided to switch back to branch, unfortunately, this happens in
>> >> branch as well. The backtrace in branch is different, and I have no
>> >> idea what is causing this, though I'm leaning towards qt since that
>> >> has changed since last time I used branch.
>> >>
>> >> FreeBSD 4.7-PRERELEASE,
>> >> gcc version 2.95.4 20020320 [FreeBSD]
>> >> KDE_3_0_BRANCH built from CVS
>> >> qt-copy 3.1.0-b2
>> >
>> > Same here.
>> > The following code, enhanced with debug output to track down the
>> > problem, is in kdebase/konqueror/konq_main.cc . Look at the comment!
>> > -------------------------------------------------------------
>> >   app.exec();
>> >
>> >  //// Temporary code, waiting for Qt to do this properly
>> >
>> >   // Delete all toplevel widgets that have WDestructiveClose, so that
>> >   we don't have // any parts loaded when KLibLoader::cleanUp is called.
>> >   QWidgetList *list = QApplication::topLevelWidgets();
>> >   QWidgetListIt it(*list);
>> >   QWidget * w;
>> >
>> >   qDebug( "count: %i", list->count() );
>> >   int i=0;
>> >   while( (w=it.current()) != 0 ) {
>> >      ++it;
>> >      ++i;
>> >      qDebug( "#%3i: Class: %s, Name: %s", i, w->className(), w->name()
>> >      ); if ( w->testWFlags( Qt::WDestructiveClose ) )
>> >           delete w;
>> >   }··
>> >
>> >   KonqMainWindow::s_crashlog_file->remove();
>>
>> Adding:
>>
>> @@ -137,6 +139,7 @@ int main( int argc, char **argv )
>>    QWidgetListIt it(*list);
>>    QWidget * w;
>>    while( (w=it.current()) != 0 ) {
>> +     qDebug("Testing:%s, flags=%d", w->className(),  w->testWFlags(
>> Qt::WDestructiveClose ) );
>>       ++it;
>>       if ( w->testWFlags( Qt::WDestructiveClose ) )
>>            delete w;
>>
>> In the debug output I get:
>> ....
>> Testing:QWidget, flags=0
>> Testing:KonqMainWindow, flags=0
>> Testing:KPopupMenu, flags=0
>> ......
> Funny. So this whole loop simply does nothing since none of the widgets
> has WDestructiveClose set. Maybe it id something in previous Qt versions.
>>
>> But in KonqMainWindow ctor, we have:
>> KonqMainWindow::KonqMainWindow( const KURL &initialURL, bool
>> openInitialURL, const char *name )
>>
>>  : KParts::MainWindow( name, WDestructiveClose | WStyle_ContextHelp )
>>
>> So it probably somehow gets cleared or lost..
> I searched for it but could not find out where it gets lost, just found
> two places where it was set again. I think it must be somewhere in Qt.

I belive this is due to this change:
- QWidget
        Clear WDestructiveClose before calling deleteLater() on
        widgets. Event processing during destruction might otherwise
        have another close-event come along which would issue another
        deleteLater() call. Added a new function toggleShowHide(bool show).
        Simplified visible() handling and added a convenience property
        "shown" and a write function for "hidden". Save wflags in
        showFullScreen and restore them in so flags are remembered
        correctly.

WHat apparently happened during my debug session, if my gdb-skills aren't 
tricking me, was that the following got executed in QWidget:
if ( testWFlags(WDestructiveClose) ) {
        clearWFlags(WDestructiveClose);
        deleteLater();
}

... And then the event loop got promptly exited, without the main window 
actually getting deleted (my breakpoint in its destructor didn't trigger, 
of course)


> I've done some more investigation.
> If you take a look at kdelibs/kdecore/kapplication.cpp, you will find this
> in KApplication::~KApplication() :
<snip>
Interesting, but what I am not getting is why my BT is quite different then. 
In the crash saw, Valgrind shows a few invalid reads in 
KIO::ProtocolManager::readConfig (or something like this, unfortunately 
don't have the output handy); followed by a jump to address 0.

> it does not crash anymore in file manager mode but there is still a crash
> when closing konqueror from "normal" html mode.
Ah, I tested with HTML..

-Thanks
Maksim.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]