For me, it is deadlocking - while we are waiting on the condition variable,
the tear down of the actual LOK / document is not progressing, because it is
waiting on something.
I was unable to get to the bottom of this in a reasonable time, so just
disabled the test for the moment; Ash is working on a similar problem I think,
so let's see if his solution helps here too (or can be applied the same way or
something).
Without this, the unit-prefork gives unpredictable results depending on
whether the entire unit test run output is redirected to another logfile or
not (as then the stdout is inherited, and points to an unexpected place).
Maybe we should just exclude the fd 0, 1, 2 from the testing; but this is good
enough for now.
UnitPrefork got what I assume is one of those PING frames that
ChildProcess::isAlive() sends before the actual reply when it sent the
"unit-memdump" message, and did not like it. Uncommenting the line
that outputs the "memory stats" message it expects showed:
Got memory stats 'PING'
Followed by:
Assertion `tokens.count() == 2' failed.
Fix by factoring out the handling of PING frames, PONG frames, and the
pseudo-PONG frames that we send ourselves in reply to PING frames into
a new function IoUtil::receiveFrame(). Use that in a couple of
places. (Probably should use in many more places.)
Getting past this then leads to later cppunit tests again being run,
and their failures then again showing up...
New unittests to verify TileCache logic on the unit level.
Change-Id: Ia36181e850b349abb88ba5f04f1e5244771bacc6
Reviewed-on: https://gerrit.libreoffice.org/24574
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Indeed, tests are built when invoking make in loolwsd
directory, thereby helping catch build errors in test
before committing.
Change-Id: I34cffcb5d0aed6485e578cf20f64217bee337d23
Reviewed-on: https://gerrit.libreoffice.org/24573
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Since lokit process counting waits until WSD
is ready (i.e. until it has created lokit processes,)
there is no need to sleep explicitly anymore.
Provided, of course, we always call the lokit
process counter before running any tests, which we
currently do.
Change-Id: Idf7ad925688251f1c81ef8628530714d2dc92d9c
Reviewed-on: https://gerrit.libreoffice.org/24528
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
As this assert fails at the moment (it did even before my previous
commit), I can't be 100% sure it is correct now. So sue me. Or revert
both my changes.
The test was unreliable, but any change there made it reliable, so not sure
yet what was the root cause - but at least this should help seeing the
brokeness once it appears again.
WebSocket::receiveFrame() does not null-terminate the buffer even when
it successfully reads something into it, even less when it
doesn't. (Why would it, as it is perferctly fine to transmit WebSocket
(binary) frames that contain zero bytes.) So the 'received' string was
always full of random bytes.
