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

List:       kde-devel
Subject:    Re: Race Condition Issue with KJob and QNetworkAccessManager
From:       Frank Reininghaus <frank78ac () googlemail ! com>
Date:       2013-03-05 10:53:13
Message-ID: CAFoZWWjramnBMEv8T5_6-xeJ86WT4HU8hpLVFVfEOpoGwFvExQ () mail ! gmail ! com
[Download RAW message or body]

Hi Adrián,

2013/3/4 Adrián Chaves Fernández:
> Hi,
> 
> There is not much I can add to what I already posted here: \
> https://forum.kde.org/viewtopic.php?f=64&t=110250 
> Last Saturday I was trying to fix a test in libmediawiki. After several \
> hours (12, I’m ashamed to admit) the only thing I could come up is with a \
> simple 6-file compilable example to reproduce the issue (see the forums \
> post). 
> To sum things up, the test starts a thread that runs a QTcpServer on a \
> certain port, and then executes (exec()) a KJob. The job sends a request \
> to the server, and after processing the reply, it finishes. This \
> procedure is repeated in the tests several times, with different data, to \
> check the results. And it fails from time to time, with different \
> combinations of data. The error, as it runs out, is not the server reply; \
> it’s that the server ocasionally gets a connection from the KJob twice — \
> while the connection is requested from the job only once. 
> In my simplified example, I just create the job and the server thread in \
> a loop, get the job to call the server, finally count the requests the \
> server got, and start again. When the server gets more than one request \
> in a loop, I print “WTF!”. With 10000 loops, I bet you get some WTF! just \
> like I did. 
> I’m not too experienced in Qt/C++/KDE, so I actually don’t know if the \
> reason is a bug in Qt, a bug in KJob, a bad implementation of the \
> FakeServer class, or that I just got it all wrong. I just hope any of you \
> guys know or can figure it out from the example provided in the forums \
> post, and can help me get past this. 
> Thanks,
> Adrian
> 
> PS: I’ve considered not counting the server request in the test, or using \
> a “sleep()” function (which might solve the problem), but we all now \
> dirty solutions like these will eventually come back, hiding an actual \
> bug that does not get tested properly, or increasing the time needed to \
> run the batery of tests for no reason. Not to mention that those dirty \
> solutions would likely hunt me in my dreams!

I'm not a network expert, and I don't know what the cause of the
problem is, but I noticed two things:

1. I think the access to "m_request" in FakeServer::*Request() needs
to be protected by locking m_mutex. Doing that does not seem to fix
the issue, but not protecting it might lead to other problems at some
point.

2. The class FakeServer follows the "You're doing it wrong" pattern
(it contains the line "moveToThread(this);") , see

http://blog.qt.digia.com/blog/2010/06/17/youre-doing-it-wrong/
http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html

This might or might not be part of the problem.

Best regards,
Frank

> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to \
> > unsubscribe <<


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