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>
