Bug 416895

Summary:	kdeinit5 crashes in KIO::SlaveBase::waitForAnswer() after return from suspend
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	Frank Fischer <frank-fischer>
Component:	HTTP	Assignee:	kdelibs bugs <kdelibs-bugs-null>
Status:	REPORTED ---
Severity:	normal	CC:	frank-fischer, nate, nicolas.fella
Priority:	NOR
Version First Reported In:	5.66.0
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Bug Depends on:
Bug Blocks:	461969
Attachments:	backtrace of crash

Description Frank Fischer 2020-01-29 09:04:08 UTC

Created attachment 125511 [details]
backtrace of crash

Whenever I return my laptop from suspension (after a few minutes), kdeinit5 crashes with the attached backtrace. I think this is related to Bug 402646, but in my case the culprit seems to be from a http/dav connection (it could be a synchronization connection in the background for a calendar).

I've tried to track down the bug a little. It seems that the function KIO::SlaveBase::waitForAnswer hits a qFatal if the received response type (or "command") is not the expected one. In particular, the syslog says

kdeinit5[9992]: Fatal Error: Got cmd 77, while waiting for an answer!

If I understand the code correctly, 77 means CMD_SPECIAL, which is not one of the expected commands checked by the call to "isSubcommand", hence the qFatal is hit.

I can only speculate what the reason is, but I would suspect some kind of race condition (caused by the suspend), the received message belongs to some other request or so.

Anyway, the main question to me is in this case ... why is there this qFatal? If the received message originates from a (potentially) external source (please forgive me if this assumption is wrong, I am not really familiar with the kio code), then any received message could contain garbage for whatever reason. So wouldn't it more sensible to return with an error instead of crashing the program? (i.e. replace the call to qFatal by "return -1" or so, so that it is the task of the caller to handle the error correctly)


Linux/KDE Plasma: Arch Linux
(available in About System)
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66
Qt Version: 5.14.0

Comment 1 Nate Graham 2020-01-29 16:18:32 UTC

Would you be interested in submitting a patch to fix the issue, or at least downgrade it to a warning?

Comment 2 Frank Fischer 2020-01-29 16:28:48 UTC

(In reply to Nate Graham from comment #1)
> Would you be interested in submitting a patch to fix the issue, or at least
> downgrade it to a warning?

Sure, I could do this. However, I'm totally unfamiliar with the kio code and do not know whether just returning an error code is ok with the rest of the code. In particular, I do not know whether this would result in some kind of inconsistent or invalid internal state of the slave (are there some assumptions about the internal state? Is all code expected to reset internal date to some valid state in case of an error, e.g. by cancelling the active connection?). So, in any case I would need some assistance to verify whether my changes make sense.

Comment 3 Nate Graham 2020-01-29 17:24:52 UTC

One of the best ways to ask these kinds of questions is to submit a patch with "[RFC]" prepended to the title; the maintainers and other interested parties willbe able to answer your questions.

Alternatively you could ask in the #kde-devel freenode IRC/Matrix room before submitting.