[Interest] advice on debugging a qnetworkaccessmanager/qnetworkreply issue

[Justin Ferguson]

Hi,

I'm running into an issue in an application that I so far cannot
totally adequately explain why its occurring; I'm not posting any code
in this email simply because I want to describe the issue and see if
there is anything obvious I am missing when trying to debug the issue
and then failing that I have no qualms posting the code.

Essentially, I have a window which creates two objects that share a
qnetworkaccessmanager object that do two separate http requests. I
connect the finished() signals for the qnetworkreply to the objects
themselves and process the data and then call an init() function that
actually does the network requests. The complication I am running into
is that 'sometimes' (probably ~3 out of 5 runs) the second objects
call to qnetworkreply->readall() is returning an empty qbytearray,
whereas other times it works without a hitch. The next oddity is that
if I change the order so that the second object's init() is called
first, then it always works without a problem.

I could just change the order and be done with it, but I suspect I've
got some issue that will just crop up later and well, it seems wrong
to fix my issue that way.

I've verified that the request is sent and read from the same thread,
that there is no error in the reply and via a packet sniffer that the
data is actually arriving. More over, I am being mindful to
qnetworkreply->close() and qnetworkreply->deleteLater() the replies
(two instances of qnetworkreply that are instance variables for the
objects in question). The object instances are not going out of
scope/getting destructed; both are allocated on the heap and atm they
just leak because I never destroy them & I've verified that neither
destructor is being called in a debugger. The network access manager
is not going out of scope/getting destructed, etc. This code is
executing prior to the main event loop being executed if that matters
any.

Has anyone run into this? I'm not sure what else to check, there seems
to be no real rationale but the behavior to me says its going to be a
race/state condition potentially in the qt library itself, but I
wanted to see if anyone had encountered this prior to grabbing a six
pack and walking through the assembly to determine what exactly is
occurring.

As I said, I have no issue posting the code, I just wanted to pick
peoples brains first and look through my code with any suggestions
people might have before doing so.

Best Regards,

Justin N. Ferguson