site is roisdecaux.fr

On Monday 25 July 2005 10:10, Matthieu Pupat wrote:
> site is roisdecaux.fr


Are you sure? Host not found here...

sorry roisdecaux.free.fr

It's hard to tell but by the backtrace it seems a KIO problem.
I tried on my system and it crashes sometimes but not always. The backtrace is 
related to KIO but is not exactly the same for all crashes.
Maybe a KIO expert can give some help here...

Another backtrace after installing kdelibs-debuginfo

*** glibc detected *** klinkstatus: corrupted double-linked list: 0x08b84b28 ***
======= Backtrace: =========
/lib/libc.so.6[0x73feed]
/lib/libc.so.6[0x74108d]
/lib/libc.so.6(malloc+0x74)[0x742792]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QGArray6resizeEjNS_12OptimizationE+0x95)[0x467c96f]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QGArray6resizeEj+0x2c)[0x467c9a0]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZNK13QWindowsStyle18drawComplexControlEN6QStyle14ComplexControlEP8QPainterPK7QWidgetRK5QRectRK11QColorGroupjjjRK12QStyleOption+0x1001)[0x46fcad3]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN13QListViewItem13paintBranchesEP8QPainterRK11QColorGroupiii+0x102)[0x4482ec2]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN9QListView18drawContentsOffsetEP8QPainteriiiiii+0x5b9)[0x4488651]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN11QScrollView18viewportPaintEventEP11QPaintEvent+0x29f)[0x44b9ec7]
/usr/lib/libkdeui.so.4(_ZN9KListView18viewportPaintEventEP11QPaintEvent+0x54)[0x4d09d2a]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN11QScrollView11eventFilterEP7QObjectP6QEvent+0x188)[0x44bacd0]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN9QListView11eventFilterEP7QObjectP6QEvent+0x99)[0x4485307]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QObject16activate_filtersEP6QEvent+0x5a)[0x439587c]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QObject5eventEP6QEvent+0x35)[0x43958f1]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QWidget5eventEP6QEvent+0x26)[0x43d3dec]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0x97)[0x43310cd]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0xb2)[0x4331a26]
/usr/lib/libkdecore.so.4(_ZN12KApplication6notifyEP7QObjectP6QEvent+0x1ef)[0x49f67a1]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QWidget7repaintEiiiib+0x1e3)[0x42fce3f]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QWidget7repaintEb+0x7e)[0x43cfb0c]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN9QListView14updateContentsEv+0xae)[0x44831be]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN9QListView9qt_invokeEiP8QUObject+0xfe)[0x4721930]
/usr/lib/libkdeui.so.4(_ZN9KListView9qt_invokeEiP8QUObject+0x47)[0x4d0e909]
/usr/lib/kde3/libklinkstatuspart.so(_ZN8TreeView9qt_invokeEiP8QUObject+0x47)[0x30b54b]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QObject15activate_signalEP15QConnectionListP8QUObject+0x16e)[0x4395df4]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QObject15activate_signalEi+0x6e)[0x43962b4]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN6QTimer7timeoutEv+0x29)[0x471011b]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN6QTimer5eventEP6QEvent+0x38)[0x43bbd18]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0x97)[0x43310cd]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0xd8)[0x4331a4c]
/usr/lib/libkdecore.so.4(_ZN12KApplication6notifyEP7QObjectP6QEvent+0x1ef)[0x49f67a1]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop14activateTimersEv+0x1e2)[0x4325972]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop13processEventsEj+0x58a)[0x42db35a]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop9enterLoopEv+0xad)[0x434978b]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop4execEv+0x26)[0x4349696]
/usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication4execEv+0x1f)[0x4330a99]
klinkstatus[0x804fe71]
/lib/libc.so.6(__libc_start_main+0xc6)[0x6f1de6]
klinkstatus(_ZN7QWidget22windowActivationChangeEb+0x51)[0x804ea31]
======= Memory map: ========
00111000-00157000 r-xp 00000000 03:07 522389     /usr/lib/libkparts.so.2.1.0
00157000-0015c000 rwxp 00045000 03:07 522389     /usr/lib/libkparts.so.2.1.0
0015c000-001b5000 r-xp 00000000 03:07 717776     /usr/lib/libmng.so.1.0.0
001b5000-001b8000 rwxp 00058000 03:07 717776     /usr/lib/libmng.so.1.0.0
001b8000-001d6000 r-xp 00000000 03:07 521745     /usr/lib/libjpeg.so.62.0.0
001d6000-001d7000 rwxp 0001d000 03:07 521745     /usr/lib/libjpeg.so.62.0.0
001d7000-001f4000 r-xp 00000000 03:07 586570     /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
001f4000-001f6000 rwxp 0001c000 03:07 586570     /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
001f6000-001f7000 r-xp 00000000 03:07 537398Minuterie d'alerte

On Monday 25 July 2005 21:59, Matthieu Pupat wrote:
> /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QGArray6resizeEjNS_12OptimizationE+0x95)[0x467c96f]
> /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN7QGArray6resizeEj+0x2c)[0x467c9a0]
> /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZNK13QWindowsStyle18drawComplexControlEN6QStyle14ComplexControlEP8QPainterPK7QWidgetRK5QRectRK11QColorGroupjjjRK12QStyleOption+0x1001)[0x46fcad3]
> /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN13QListViewItem13paintBranchesEP8QPainterRK11QColorGroupiii+0x102)[0x4482ec2]
> /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN9QListView18drawContentsOffsetEP8QPainteriiiiii+0x5b9)[0x4488651]
> /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN11QScrollView18viewportPaintEventEP11QPaintEvent+0x29f)[0x44b9ec7]
> /usr/lib/libkdeui.so.4(_ZN9KListView18viewportPaintEventEP11QPaintEvent+0x54)[0x4d09d2a]
> /usr/lib/qt-3.3/lib/libqt-mt.so.3(_ZN11QScrollView11eventFilterEP7QObjectP6QEvent+0x188)[0x44bacd0]


A crash when painting a QListView - completely unrelated.

On Monday 25 July 2005 21:12, David Faure wrote:
> A crash when painting a QListView - completely unrelated.


Perhaps Qt related?

I installed some debuginfo and ran this in gdb. I then got:

#0  0x0469e241 in QString::QString () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#1  0x04fecfd5 in KIO::Scheduler::slotSlaveDied (this=0x9463438, slave=0x959bef8) at ./../kio/slave.h:117
#2  0x04fed12e in KIO::Scheduler::_cancelJob (this=0x9463438, job=0x95a2910) at scheduler.cpp:266
#3  0x04ff7d1e in KIO::SimpleJob::kill (this=0x95a2910, quietly=true) at scheduler.h:146
#4  0x0027c9fb in LinkChecker::slotTimeOut (this=0x95a4408) at linkchecker.cpp:94
#5  0x00280bf9 in LinkChecker::qt_invoke (this=0x95a4408, _id=6, _o=0xbffec014) at linkchecker.moc:153
#6  0x04395df4 in QObject::activate_signal () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#7  0x0470e206 in QSignal::signal () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#8  0x043b3673 in QSignal::activate () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#9  0x043bbf55 in QSingleShotTimer::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#10 0x043310cd in QApplication::internalNotify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#11 0x04331a4c in QApplication::notify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#12 0x049f67a1 in KApplication::notify (this=0xbffec51c, receiver=0x95a5ea8, event=0xbffec2f4) at kapplication.cpp:549
#13 0x04325972 in QEventLoop::activateTimers () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#14 0x042db35a in QEventLoop::processEvents () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#15 0x0434978b in QEventLoop::enterLoop () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#16 0x04349696 in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#17 0x04330a99 in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#18 0x0804fe71 in main (argc=3670100, argv=0x380054) at main.cpp:97
#19 0x006f1de6 in __libc_start_main () from /lib/libc.so.6
#20 0x0804ea31 in _start ()

On Monday 25 July 2005 23:10, Matthieu Pupat wrote:
> #4  0x0027c9fb in LinkChecker::slotTimeOut (this=0x95a4408) at linkchecker.cpp:94


What does that code look like?

On Monday 25 July 2005 22:14, David Faure wrote:
> > #4  0x0027c9fb in LinkChecker::slotTimeOut (this=0x95a4408) at
> > linkchecker.cpp:94
>
> What does that code look like?

void LinkChecker::slotTimeOut()
{
    if(!finnished_ && !parsing_)
    {
        Q_ASSERT(t_job_);
        if(t_job_->error() != KIO::ERR_USER_CANCELED)
        {
            linkstatus_->setErrorOccurred(true);
            linkstatus_->setError(i18n( "Timeout" ));
            //kdDebug(23100) << "timeout: " << linkstatus_->absoluteUrl().url() << endl;

            t_job_->kill(true); // quietly
            t_job_ = 0;

            finnish();
        }
    }
}

>     if(!finnished_ && !parsing_)

The right spelling is finished_ :)

>         Q_ASSERT(t_job_);
>         if(t_job_->error() != KIO::ERR_USER_CANCELED)

error() is only available from the slot connected to result(). Is this slot connected to result()?
If yes: then don't kill it! It destroys itself already.
If no: then testing ->error() makes no sense.

>             t_job_->kill(true); // quietly

On Monday 25 July 2005 22:35, David Faure wrote:
> >     if(!finnished_ && !parsing_)
>
> The right spelling is finished_ :):)


Ups :)

> >         Q_ASSERT(t_job_);
> >         if(t_job_->error() != KIO::ERR_USER_CANCELED)
>
> error() is only available from the slot connected to result(). Is this slot
> connected to result()? 


It isn't.

> If yes: then don't kill it! It destroys itself 
> already.
> If no: then testing ->error() makes no sense.


I should had commented that if condition because I don't remember now why is 
there! Though, it must be for a reason and it's not relevant to the crash, 
anyway.
>
> >             t_job_->kill(true); // quietly

On Monday 25 July 2005 23:46, Paulo Moura Guedes wrote:
> I should had commented that if condition because I don't remember now why is 
> there! Though, it must be for a reason 

The only reason I can think of, would be a copy-n-paste error (from a slot connected to timeout),
or a wrongly investigated bug. The error isn't set before result is emitted, and the job is deleted
right after result is emitted...

> and it's not relevant to the crash,  anyway.

So what do you do in the slot connected to result()? Do you set t_job_ to 0?

Also: do you know valgrind? It's the best tool for debugging crashes, it'll tell you
immediately where the problem is.

On Monday 25 July 2005 23:39, David Faure wrote:
> > and it's not relevant to the crash,  anyway.
>
> So what do you do in the slot connected to result()? Do you set t_job_ to
> 0?


Yes.

> Also: do you know valgrind? It's the best tool for debugging crashes, it'll
> tell you immediately where the problem is.


With valgrind it doesn't crash but I can find this:

==16858== Invalid read of size 4
==16858==    at 0x4530A503: KIO::Slave::deref() (slave.h:206)
==16858==    by 0x452A5213: KIO::Slave::gotInput() (slave.cpp:314)
==16858==    by 0x452A6ACA: KIO::Slave::qt_invoke(int, QUObject*) 
(slave.moc:113)
==16858==    by 0x47A57283: QObject::activate_signal(QConnectionList*, 
QUObject*) (in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x47A578AA: QObject::activate_signal(int, int) 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x47DB16FF: QSocketNotifier::activated(int) 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x47A744BF: QSocketNotifier::event(QEvent*) 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x479F34CE: QApplication::internalNotify(QObject*, QEvent*) 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x479F366B: QApplication::notify(QObject*, QEvent*) 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x411BEF0D: KApplication::notify(QObject*, QEvent*) 
(kapplication.cpp:549)
==16858==    by 0x479E6BE2: QEventLoop::activateSocketNotifiers() 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x4799E230: QEventLoop::processEvents(unsigned) 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x47A09C60: QEventLoop::enterLoop() 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x47A09BB5: QEventLoop::exec() (in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x479F262E: QApplication::exec() 
(in /usr/lib/libqt-mt.so.3.3.4)
==16858==    by 0x8050DF7: main (main.cpp:97)
==16858==  Address 0x199226E4 is not stack'd, malloc'd or (recently) free'd

The problem seems to be in trying to kill the job before signal result is 
emmited. I can't tell for sure why the crashes happen and they doesn't happen 
always but my guess is that they happen when slot result is called almost 
simultaneously when I try to kill the job (signals data, mimetype, etc) and 
then it's killed twice.

If instead of trying to kill the job I disconnect it from my slots, no crash 
happens :) 
Do you think this is a good solution (performance wise, etc)? 
I'm still not convinced that this is an application problem... unfortunatlely, 
there's no other that tries to do such things so one can compare.

With the following kio patch, klinkstatus doesn't crash: 

Index: kdelibs/kio/kio/scheduler.cpp
===================================================================
--- kdelibs/kio/kio/scheduler.cpp       (revision 438634)
+++ kdelibs/kio/kio/scheduler.cpp       (working copy)
@@ -626,8 +626,9 @@
     }

     if (!slaveList->removeRef(slave))
-       kdDebug(7006) << "Scheduler: BUG!! Slave died, but is NOT in 
slaveList!!!\n" << endl;
-    slave->deref(); // Delete slave
+        kdDebug(7006) << "Scheduler: BUG!! Slave " << slave << "/" << 
slave->slave_pid() << " died, but is NOT in slaveLis$
+    else
+        slave->deref(); // Delete slave
 }

 void Scheduler::slotCleanIdleSlaves()
===================================================================

What do you think?

Am Dienstag 16 August 2005 17:16 schrieb Paulo Moura Guedes:
> With the following kio patch, klinkstatus doesn't crash: 
> 
> Index: kdelibs/kio/kio/scheduler.cpp
> ===================================================================
> --- kdelibs/kio/kio/scheduler.cpp       (revision 438634)
> +++ kdelibs/kio/kio/scheduler.cpp       (working copy)
> @@ -626,8 +626,9 @@
>      }
> 
>      if (!slaveList->removeRef(slave))
> -       kdDebug(7006) << "Scheduler: BUG!! Slave died, but is NOT in 
> slaveList!!!\n" << endl;
> -    slave->deref(); // Delete slave
> +        kdDebug(7006) << "Scheduler: BUG!! Slave " << slave << "/" << 
> slave->slave_pid() << " died, but is NOT in slaveLis$
> +    else
> +        slave->deref(); // Delete slave
>  }
> 
>  void Scheduler::slotCleanIdleSlaves()
> ===================================================================
> 
> What do you think?
> 

I'm not too sure - Waldo is our scheduler guy usually .)

Greetings, Stephan

*** This bug has been marked as a duplicate of 85575 ***

The patch in #16 is ok, but the problem seems to be that a slave gets deleted twice for some reason. The patch doesn't solve that.

Try to trace down why the slave isn't in slaveList anymore.