Try to make TestShellClient::testUnresponsiveWindow more robust
ClosedPublic

Authored by graesslin on Dec 23 2018, 7:01 AM.

Details

Summary

When looking at the test results on build.kde.org we see this is the
test which fails most often and it's always at the same line of code.

So I just had a look with the thought: "what's special about this code,
why could it fail?"

Looking at it we start an external process which is supposed to connect
to KWin. We wait for the process to start and then wait for the shell
client added. This assumes that at the time we handle the wait for
started the connection of the window has not happened yet.

Thinking about it, it's possible that we get the wait for started after
we added the window. So this change tries to catch this special
condition.

Diff Detail

Repository
R108 KWin
Branch
shell-client-test-robustness
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 6303
Build 6321: arc lint + arc unit
graesslin created this revision.Dec 23 2018, 7:01 AM
Restricted Application added a project: KWin. · View Herald TranscriptDec 23 2018, 7:01 AM
Restricted Application added a subscriber: kwin. · View Herald Transcript
graesslin requested review of this revision.Dec 23 2018, 7:01 AM

I don't think so.

waitForStarted is blocking without an event loop which means shellClientAddedSpy.wait is still the only place we'd process a new shell client from the Wayland event queue.

But we can ship this anyway to see, it won't do any harm.

Hmm, if it blocks, this won't help. But it gives me another idea: KWin blocks too long and the helper fails to connect to the Wayland socket and terminates.

graesslin updated this revision to Diff 48091.Dec 23 2018, 6:51 PM

Use signalspy instead of blocking wait for process start

davidedmundson accepted this revision.Dec 23 2018, 7:31 PM
This revision is now accepted and ready to land.Dec 23 2018, 7:31 PM
This revision was automatically updated to reflect the committed changes.