KIO::mimetype sync call in DocumentController::openDocumentInternal hazardous

Milian Wolff mail at milianw.de
Sun Sep 26 15:19:25 UTC 2010


Heyho,

anyone ever got this and went mad:

ASSERT: "!documents.contains(url) || documents[url]==doc" in file 
/home/milian/projects/kde4/kdevplatform/shell/documentcontroller.cpp, line 316

I found a way to get it reproducible, for me it's the second time I try 
something like this:

kdevelop -d kate

first run works, second will fail.

Lots of debug output later I found out what the reason is:

openDocumentInternal is called twice, within the same thread, without the first 
returning. The reason for that? KIO::mimetype job executed syncronously:

a) mimeType->is( "application/octet-stream" ) is most probably always true, 
since ->is() honors mimetype inheritance and afaik this is a quite generic 
mimetype that most others inherit. so this should be fixed to ->name() == 
"application/octet-stream". I'll do this later, but it doesn't fix the real 
bug.

b) look at this code:

                    // Try harder using KIO. This also allows looking at the 
content of remote files.
                    KIO::MimetypeJob* job = KIO::mimetype(url, 
KIO::HideProgressInfo);
                    if(job->exec())
                        mimeType =  KMimeType::mimeType(job->mimetype());
                    delete job;

looks nice, and safe, doesn't it? well, wrong. Let me quote from the 
documentation of KJob exec():

     * Should you indeed call this method, you need to make sure that all 
callers are reentrant,
     * so that events delivered by the inner event loop don't cause non-
reentrant functions to be
     * called, which usually wreaks havoc.

indeed, it does wreak havoc here! Somehow the eventloop black-magic leads to 
another call to 
KDevelop::WorkingSet::changedWorkingSet which eventually tries to get the same 
document from the controller again => fail.

So how can we fix this? Can someone explain how I could make 
openDocumentInternal reentrant? Just by coping with the case the assertion 
currently prevents? I sadly don't see a way to use the safe async KJob api 
here :-S

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100926/63111d2d/attachment.sig>


More information about the KDevelop-devel mailing list