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

List:       kfm-devel
Subject:    Re: old html cache bug -> kfm segfaults
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-01-27 1:13:56
[Download RAW message or body]

Found it !
Below are explanations of how I found it, and what was the reason.
Skip it all if you're not interested - however it's a good example of how
to track such a well hidden bug...

I used Torben's method : printfs.
gdb wasn't wrong, it just didn't help.

Background information :
HTMLCache holds a static list of HTMLCacheJob, called staticJobList.
The list is setAutoDelete(false)
A HTMLCacheJob is a KIOJob (inherits from it).


Here we go :

starting for loop...
count = 3
job 0x82796a0
getSrcURL : http://www/Images/som_fra7.jpg
job 0x82bffd0
getSrcURL : http://www/Images/som_fra8.jpg
job 0x82c0688
getSrcURL : http://www/Images/som_fra9.jpg
OK

---> We have a staticJobList with 3 elements.

added 0x82cb010 to staticJobList

---> We have a staticJobList with 4 elements.

deleting job 0x82788a8
---> don't know this one (?!!)
deleting job 0x82bffd0
deleting job 0x82796a0
deleting job 0x82cb010
deleting job 0x82c0688

---> deleting the ones that are in the list. They're _not_ removed from the 
list !!! (I added other debug output before every removeRef() call !)
 

---> And then, later, when re-opening the same window :

starting for loop...
count = 4
job 0x82796a0
getSrcURL : ˜—)
job 0x82bffd0 
<SIGSEGV>

---> Wow. We have a list with deleted objects in it !
Of course, the items in gdb looked fine, but they pointed to deleted objects....


After that, I investigated a bit further, adding other debug() calls, and what
happened was that HTMLCacheJob::slotJobFinished did a "emit finished(this)"
which didn't call HTMLCache::slotJobFinished, even if the connect was done.

It's very difficult to find why a signal-slot mechanism doesn't work. Are
there tools that can be called in a printf such as 'print me all the
receivers for the slot xxx' ? That would help.

Anyway.
After adding more calls to debug() all over the place, it appeared that
this was due to the HTMLCache destructor being called (when closing the
first window), so the jobs were disconnected from the parent HTMLCache.
Ah.

So we have to stop the jobs before deleting the parent. Then I realised the 
method already existed but was never called !!! There is a static void
quit() in HTMLCache, but nobody calls it. And it does what we need...
So the fix was really simple - even though I had to fight during 3 hours with
this bug - :

diff -u -p -r1.17 htmlcache.cpp
--- htmlcache.cpp       1998/12/20 17:15:10     1.17
+++ htmlcache.cpp       1999/01/27 00:59:14
@@ -209,6 +209,7 @@ const char* HTMLCache::isCached( const c
 
 HTMLCache::~HTMLCache()
 {
+    quit(); // Let's delete all running jobs ! David.
     instanceList->removeRef( this );
 } 


Wow.
"Small is beautiful" as Waldo said recently...

Ok, now there's another one that occured if I did the same thing closing
the first window a bit earlier. Something with the toolbar. Hum...

-- 
 ____________________________________________________________________
|                                                                    |
|  David FAURE                                                       |
|  E-mail : David.Faure@insa-lyon.fr, faure@kde.org                  |
|  http://www.insa-lyon.fr/People/AEDI/dfaure/index.html             |
|____________________________________________________________________|

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