Bug 416895 - kdeinit5 crashes in KIO::SlaveBase::waitForAnswer() after return from suspend
Summary: kdeinit5 crashes in KIO::SlaveBase::waitForAnswer() after return from suspend
Status: REPORTED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: HTTP (show other bugs)
Version: 5.66.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks: 461969
  Show dependency treegraph
 
Reported: 2020-01-29 09:04 UTC by Frank Fischer
Modified: 2022-11-17 22:57 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
backtrace of crash (3.14 KB, text/plain)
2020-01-29 09:04 UTC, Frank Fischer
Details

Note You need to log in before you can comment on or make changes to this bug.
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.