Transfer LOK callback processing into our main thread if necessary.

While we are processing data in the poll handler, we can have
another helpful thread from the core sending things to us:

loolforkit(Socket::assertCorrectThread(char const*, int))
loolforkit(WebSocketHandler::sendFrame(std::shared_ptr<StreamSocket> const&, char const*, unsigned long, unsigned char, bool) const)
loolforkit(WebSocketHandler::sendMessage(char const*, unsigned long, WSOpCode, bool) const)
loolforkit(Document::postMessage(char const*, int, WSOpCode) const)
loolforkit(Document::sendFrame(char const*, int, WSOpCode))
loolforkit(ChildSession::sendTextFrame(char const*, int))
loolforkit(ChildSession::loKitCallback(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&))
loolforkit(Document::GlobalCallback(int, char const*, void*))
/core/instdir/program/libsofficeapp.so()
/core/instdir/program/../program/libfwklo.so()
/core/instdir/program/libscfiltlo.so()
/core/instdir/program/libexpwraplo.so()
/core/instdir/program/libooxlo.so(oox::core::FastParser::parseStream(com::sun::star::xml::sax::InputSource const&, bool))
/core/instdir/program/libooxlo.so(oox::core::FastParser::parseStream(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&))
/core/instdir/program/libooxlo.so(oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&))
/core/instdir/program/libscfiltlo.so()
/core/instdir/program/libcomphelper.so(comphelper::ThreadTask::exec())
/core/instdir/program/libcomphelper.so()
/core/instdir/program/libuno_salhelpergcc3.so.3(salhelper::Thread::run())
/core/instdir/program/libuno_salhelpergcc3.so.3()
/core/instdir/program/libuno_sal.so.3()
/lib/x86_64-linux-gnu/libpthread.so.0()
/lib/x86_64-linux-gnu/libc.so.6(clone)

This is most likely from eg. threaded parsing of various file formats,
or progress messages while loading / saving, sent while the SolarMutex
is locked.

We assume that:
+ there will only ever be one thread running inside kitPoll
this is enforced by vcl/headless.
+ and so, we can safely mutate SocketPoll and Socket buffer
state from this thread.
+ there are only two entry points for callbacks from threads
in core - which are both instrumented, and if necessary
their work is shifted to this thread.

Memory corruptions matching the above trace, suggesting that
multiple writes have collided between kitPoll and an event
callback have been seen in the wild.

Change-Id: I5b084cbfec1ea326b6e17c9e5590a8c8e35b3854
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>

1 files changed, 5 insertions, 0 deletions

diff --git a/kit/Kit.cpp b/kit/Kit.cpp
index 403e370337..09713cbe9f 100644
--- a/kit/Kit.cpp
+++ b/kit/Kit.cpp
@@ -149,6 +149,11 @@ static void flushTraceEventRecordings();
 // socket buffer & event processing in a single, thread.
 bool pushToMainThread(LibreOfficeKitCallback cb, int type, const char *p, void *data);
 
+// Abnormally we get LOK events from another thread, which must be
+// push safely into our main poll loop to process to keep all
+// socket buffer & event processing in a single, thread.
+bool pushToMainThread(LibreOfficeKitCallback cb, int type, const char *p, void *data);
+
 #if !MOBILEAPP
 
 static LokHookFunction2* initFunction = nullptr;