fifr added a comment.
Well, the main problem for me is that I do not know what `waitForAnswer` is
supposed to to and in which situation it is supposed to be called. The
assumptions that I made are the following:
- it is called to receive an answer after some kind of command (that should
trigger the answer from peer) has been invoked
- this answer is potentially received from an external source, e.g. a network
connection (it's some KIO code in the end ...)
- the validity of this answer has not been verified before, i.e. it could be
possible that the incoming data is wrong (e.g. transmission error of any kind)
Therefore, the call to `isSubCommand` is basically (part of) the verification
that the incoming data is correct.
The real question, that I simply cannot answer, is whether it should be
**logically** impossible that `isSubCommand` returns false in this case. Only
then aborting with `qFatal` would be justified (in my opinion), otherwise the
case that `isSubCommand` returns false should be handled properly, not just
aborting.
My problem is that I do not understand the underlying architecture of the
code **at all**. So I hoped that someone who knows the code could comment on
whether it is logically possible (given that for whatever reason invalid data
has been received by the call to `d->appConnection.read(&cmd, data)` a few
lines above) that `isSubCommand` fails or not. For me this judgement is
impossible. Even if I could reproduce the error reliably (should be possible at
least on my system, but whole architecture seems to be very complex so that I
do not even know where to start) I would not know whether the problem is here
in this code (`isSubCommand` could fail) or somewhere else (`isSubCommand` must
not fail), because I do not know how it is **supposed to be**.
After all, I would be very happy to assist and provide further information, I
just do not know what to do.
Btw: I've been using this patch for several weeks now and the problem
vanished completely.
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D27385
To: fifr, #frameworks, dfaure, meven
Cc: broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
