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:⭐:xml::sax::InputSource const&, bool))
/core/instdir/program/libooxlo.so(oox::core::FastParser::parseStream(com::sun:⭐:uno::Reference<com::sun:⭐: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>
f8a5edb995