When two sockets send data to each other in blocking
mode, they can both wait until the other end-point's
buffers are free enough to receive the data being
sent. Since in LOOLWebSocket we lock both send and
receive with the same lock, this prevents the
reader thread from freeing the buffer while we try
to send data. But since our peer is in the same
dilemma, neither of us will make progress--deadlock.
Since sockets are full-duplex, they are capable of
handling two way communication concurrently. Poco
seems to not share data between them either, so
this seems safe.
Change-Id: I1fd68cd4fb3b4250b93c8f94cd42e49ee78f6650
Reviewed-on: https://gerrit.libreoffice.org/34194
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When cleaning up DocumentBrokers we hold
the global DocBrokersMutex. So we need
to keep this lock as short as possible
to serve new requests.
However when a given DocBroker is locked
and busy, or worse deadlocked, we'd end
up blocking any new client connection.
So here we skip busy DocBrokers while
cleaning up.
Change-Id: I188c9abc34fd90c4ba388894b47c1ab08d185129
Reviewed-on: https://gerrit.libreoffice.org/34119
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
...and not just when loading a new document.
Change-Id: If5b19e500c59a8d1fcf96666ef244833c05e2b99
Reviewed-on: https://gerrit.libreoffice.org/34118
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Poco documentation for getPath says
"Returns the decoded path part of the URI."
Unfortunately, this isn't true for encoded URIs.
It ends up returning the full URI (albeit decoded).
So we decode the URI ourselves before calling
getPath to ensure it will be able to parse it
and return only the path, as promised.
Change-Id: I23ed65f753f7e5db74ce7833b812f566b1964037
Reviewed-on: https://gerrit.libreoffice.org/34117
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The payload of paste can't have length 0.
Now we silently skip such cases, although perhaps we
should be more strict and disconnect the offending
client.
Change-Id: Iaa2e7373277f9e7d85209aec56a2f8ee0ef7e801
Reviewed-on: https://gerrit.libreoffice.org/34112
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
There is no need to use `ps` here as reading
directly is trivial and has far less overhead.
Change-Id: I27d0432c1f3a9d35763d67fc445d8bd828f1b27e
Reviewed-on: https://gerrit.libreoffice.org/34052
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
To perform one fuzzing iteration, use something like:
./loolwsd_fuzzer --config-file=loolwsd.xml --o:lo_template_path="/opt/libreoffice/instdir" --o:storage.filesystem[@allow]=true --fuzz=/tmp/looltrace
Change-Id: I27210d55a65f75e7d51e05c2f5f999acb758c4b1
By default snapshots are disabled, since trace recording
is enabled, to avoid unexpectedly flooding the disk.
Change-Id: I6c8728e14801f0a72accde1378455ec0e6046e3e
