removed use of Poco::StringTokenizer from the test directory using LOOLProtocol::tokenize and std::vecor<std::string>
Change-Id: I20fc2e0ef0d0d8fc959fee7972aa095f2581c181
Reviewed-on: https://gerrit.libreoffice.org/82565
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
Sometimes core renderes with sub-pixel differences
(the crosshair at the corners of the Writer pages
show line anti-aliasing differences). This causes
failure of the tests that count the tile deduplication.
We now tolerate when we get an unchanged tile twice,
assuming it was due to such a rendering difference,
but we re-trigger another change and this time we
don't expect any extra tiles, no more than two
variations of the anti-aliased crosshair was
observed.
We also move some duplicate code into utility
functions to improve readability and reuse.
Reviewed-on: https://gerrit.libreoffice.org/81196
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 9603597fd1aaecb27893792cfd2d243e450b58b8)
Change-Id: I1a66732dd3443bfbd770d8dc65721571dfa08615
Reviewed-on: https://gerrit.libreoffice.org/81572
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
There are numerous race conditions between issuing
action and getting the events. This causes a
mismatch, such that the events from SelectAll
is received when waiting for the events for a
subsequent action (say, Delete).
To make matters worse, sometimes Core issues
an invalidation whilst sending the events for
an action, and this completely messes our
accounting of what events we expect.
This latter could also be an issue with real
clients, however it's less likely to be
disruptive. Still, it is possible that
the client doesn't get key events
because Core had a hiccup, which breaks
the tests.
For the tests at least, the solution is to
re-issue the last action, such that we make
sure that we move forward only when the correct
event is received, or we timeout waiting.
The end results is that tests now don't fail
nearly as often as they used to.
Reviewed-on: https://gerrit.libreoffice.org/80894
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 050403daf04d6b36ef850006ba4a15eab6be9afc)
Change-Id: Ib1a658846061990649987ca083915a49c1fb092a
Reviewed-on: https://gerrit.libreoffice.org/81565
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The SVG can have self-closing tags, which wasn't accounted
for. This meant the actual SVG didn't match the expected.
Reviewed-on: https://gerrit.libreoffice.org/80895
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 93abce99d02aa417feeae12f9232b0be83a74e35)
Change-Id: I749ba7f59351cf635fdc1cd30b3be5260b3c6b16
Reviewed-on: https://gerrit.libreoffice.org/81566
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Useful to match with the timestamps in WSD
and align events when investigating test failures
(or when trying to figure out the activity matching
certain actions/commands).
Reviewed-on: https://gerrit.libreoffice.org/80893
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit b06ea528fe9dac854a18d4a9255ac598830dbb2c)
Change-Id: I73a0eb8e55ee7ca1b8935bd42468f53d7a82f80b
Reviewed-on: https://gerrit.libreoffice.org/81564
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
In case we fail to open the document, try again in 2 seconds (same value
as in HTTPServerTest::testConvertTo()). This seems to be needed fore
core.git dbgutil builds, but don't do that unconditionally, in case the
sleep is not needed for optimized core.git.
Change-Id: I4585d1f273bfa5fffc4b02bc6107f27a2c9e1280
Dump the SVG we actually get as a .new file for easy upgrade and
comparison on mismatch.
Change-Id: I607a97ff27a9bf480524efc31877e46d74c5ee3d
Reviewed-on: https://gerrit.libreoffice.org/71681
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Avoids tests crashing with obscure memory errors re-allocating the
string buffer; and hopefully cleans up the output too.
Change-Id: I3e38680c15129e84f0c7dd8cada3b505cf08ad34
And improve the logging support in unit-tests to
help troubleshoot issues faster and more accurately.
Also makes the code more readable (hopefully).
Change-Id: I4f8aafb5245e2f774b03231591a74544f9ec84aa
Reviewed-on: https://gerrit.libreoffice.org/48645
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
make check fails for me like this:
Test name: HTTPCrashTest::testCrashKit
equality assertion failed
- Expected: 1001
- Actual : 65535
Failures !!!
Run: 1 Failure total: 1 Failures: 1 Errors: 0
But when I run loolwsd and ./test manually (./test is invoked by gdb) and I
step through the code, then the test passes. So I guess what happens is that we
read from the socket too fast, and the error we're looking for is just not
there yet. Add the same amount of sleep here (0.5s) than what's used in
connectLOKit(), with that the test passes fine.
(The sleep is in test-only code.)
Change-Id: Iff105c45f21c40c2fb0a649fc9fd9a9065e7c952
Reviewed-on: https://gerrit.libreoffice.org/38846
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The following scenario causes rendering failure
where blank tiles are returned.
1. Load doc where the cursor is saved to a top cell.
2. Page down (typically several 100th row).
3. Load a new view to the same doc (do nothing else).
4. In the first view up-arrow to move cursor and invalidate.
5. New tile is rendered incorrectly.
Change-Id: I06c7627d1b74d9e3be3e83d9d9a09cb5479ba660
Reviewed-on: https://gerrit.libreoffice.org/37129
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This was a workaround to Poco's limitation
of requiring socket receiveFrame be given
preallocated buffer, which couldn't be
exceeded by a larger payload. This meant
the receiver had to know the maximum
payload in advance.
Since only the Kit uses Poco sockets,
and the Kit never receives large payloads,
this preamble is now obsolete.
100% (94/94) of old-style tests PASS.
Change-Id: I76776f89497409e5755e335a3e25553e91cf0876
Reviewed-on: https://gerrit.libreoffice.org/36037
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Now it is possible to use:
./loolwsd_fuzzer --config-file=loolwsd.xml --o:storage.filesystem[@allow]=true --o:logging.level=fatal --fuzz=/tmp/looltrace
Ie. no need to specify the LibreOffice install location. Ideally worth
disabling the logging output too, to gain higher performance.
Change-Id: I4fa5f275cd4f4a52fe2cd07e658cea726f6f31c2
This makes debugging much easier as one can
readily match WSD logs with a given test.
Change-Id: I8f2c83d67189038699af3f24dee205bc7efb5c28
Reviewed-on: https://gerrit.libreoffice.org/32860
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
canceltiles is not guaranteed to prevent
tiles from getting sent back to the client.
There is an obvious race between receiving
tile requets and cancelling them.
This reduces failures by repeating the
unittest when there is spurious failure.
Change-Id: Icf299e2212e175dc4c0cbc1d2f91c37725f2b261
Reviewed-on: https://gerrit.libreoffice.org/32631
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Messages larger than a certain size are preambled
with a 'nextmessage' message that hold the size
of the subsequent message.
This is a workaround to a limitation the Poco
WebSocket API where if the buffer size is
smaller than the received frame the socket
ends up in a bad state and must be closed.
Unfortunately the new API that avoids this
workaround is not yet released by Poco.
Here we minimize the need for 'nextmessage'
to truely large messages. The limit is now
raised from above 1KB to over 63KB.
We may raise this limit further, but that will
cost each socket that much dedicated buffer size.
Change-Id: I01e4c68cdbe67e413c04a9725152224a87ab8267
Reviewed-on: https://gerrit.libreoffice.org/31286
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
