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
