Crash in kdelibs

[Michael Brade]

Hi,

sorry for not answering earlier, I didn't have time to read the masses of mail 
on kde-core-devel exactly because of this bug - it was probably one of the 
hardest KDirLister bugs up to now and I want to get it fixed for KDE 3.4. 
Only the code is missing, I'm currently writing it.

And please use a more descriptive Subject, like putting the word 
KDirLister(Cache) in it, then I would have seen the mail earlier.

>  I experienced a crash in kdelibs that was reported by some users in the
> past, but could never reproduce it until today (and I thought it's
> already fixed). The BT is below, the reason of the actual crash is
> clear (holders is NULL in KDirListerCache::forgetDirs), and somebody
> already expected to be NULL in some cases as there is a Q_ASSERT there:
No, I did not expect it to be 0, it is an invariant of KDirLister that it 
*must not* be 0. The assert helps for debugging in case it actually becomes 
0, which happened now.

> The first question is how this can be NULL and how can one avoid it to
> be NULL.
Here's my analysis: ListerA holds e.g. lan://localhost. The job finished with 
an error, so the item is not set to be complete. ListerA starts to list lan:/ 
again, lan://localhost/ is discarded (since not complete), and a new job is 
started. There is an entry "lan:/" in urlsCurrentlyListed and itemsInUse.

At that moment ListerB comes along requesting lan:/ as well. It gets connected 
to the running job. Immediately afterwards listerA is stopped (even before 
the job was able to redirect to lan://localhost/). This moves lan:/ to 
urlsCurrentlyHeld (problem starts!). listerA now holds lan:/.

Then the job redirects to lan://localhost/, but only the lan:/ in 
urlsCurrentlyListed is redirected to lan://localhost/, the item in itemsInUse 
is renamed. (that item could also be in itemsCached in really gross 
circumstances!!) The job then finishes with an error.

So now there is lan://localhost in itemsInUse (with 2 KDirWatch references!) 
and in urlsCurrentlyHeld. But there is also a lan:/ in urlsCurrentlyHeld 
(with no corresponding entry in itemsInUse, violating one of KDirListerCaches 
invariants).

Finally, listerA requests lan:/ again with reload=true. listerA's dirs are 
discarded, but when looking for lan:/ in itemsInUse we get a NULL which is 
dereferenced later -> KABOOM.

As if that wasn't enough, this "little" bug causes some other effects as well: 
when urlA gets redirected to urlB, the urlA is not in itemsInUse or 
itemsCached anymore. Subsequent listings of urlA then result in multiple 
entries in itemsInUse/itemsCached and urlsCurrentlyHeld. No idea about the 
exact consequences of that.

I'll fix all those issues by adapting KDirListerCache::slotRedirection().

BTW, can you give me the number of the bugreport and how to reproduce your 
version of the bug?

Cheers,
-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3: The Next Generation in Desktop Experience
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050303/6ce754f9/attachment.sig>