https://bugs.kde.org/show_bug.cgi?id=458448
Bernie Innocenti <ber...@codewiz.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sit...@kde.org
--- Comment #4 from Bernie Innocenti <ber...@codewiz.org> ---
The failing check was added in this commit:
tree 74aa6a361d80ac78a36f4e9827cd88aed131a567
parent 7a267428fa3483137ee728ffc5bac6ba185d3052
author Harald Sitter <sit...@kde.org> Wed Aug 3 13:08:20 2022 +0200
committer Harald Sitter <sit...@kde.org> Tue Aug 9 19:15:01 2022 +0000
clear state after timeout'd special call
this fixes a crash with the sftp worker.
what happens is that when a worker uses the timeoutSpecialCommand
infrastructure they'll get a special() call before the regular dispatch
call. this would cause double-finished or double-errors emissions
because we hadn't cleared the state after the timeout special call.
to solve this problem we'll simply treat the timeout call like any other
dispatch call and verify the state and then reset it back to idle
we could also have continued but to prevent side effects of this fix
I've opted to keep the previous control flow going where the timeout
occurs in the same loop iteration as the dispatch.
diff --git a/src/core/slavebase.cpp b/src/core/slavebase.cpp
index 7f96bef8e..0ed1caf04 100644
--- a/src/core/slavebase.cpp
+++ b/src/core/slavebase.cpp
@@ -314,6 +314,9 @@ void SlaveBase::dispatchLoop()
d->nextTimeout.invalidate();
d->timeoutData = QByteArray();
special(data);
+ // special calls finished(), verify and clear the state so the
following dispatch starts with a clean slate
+ d->verifyState("timeoutSpecialCommand()");
+ d->m_state = d->Idle;
}
Q_ASSERT(d->appConnection.inited());
--
You are receiving this mail because:
You are watching all bug changes.
