Download it now!
Bug 59881 - sdremote - deadlock ...
Summary: sdremote - deadlock ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.0.0.2 rc
Hardware: Other All
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: target:4.1.0 target:4.0.0
Keywords:
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2013-01-26 01:56 UTC by Michael Meeks
Modified: 2013-01-29 11:50 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
stack traces for all frames (24.02 KB, text/plain)
2013-01-26 11:46 UTC, Michael Meeks
Details
second silly threading UNO threading issue exposed. (28.45 KB, text/plain)
2013-01-28 09:17 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2013-01-26 01:56:11 UTC
It seems that the impress UNO API can't be used outside the main thread safely. eg. I get a deadlock like this:


Thread 22 (Thread 0xac042b70 (LWP 32313)):
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:144
#1  0xb7c46cad in _L_lock_786 () from /lib/libpthread.so.0
#2  0xb7c46b65 in __pthread_mutex_lock (mutex=0x9d655b8) at pthread_mutex_lock.c:82
#3  0xb7d3c7e4 in pthread_mutex_lock (mutex=0x9d655b8) at forward.c:182
#4  0xb7f971ba in osl_acquireMutex (Mutex=0x9d655b8) at /data/opt/libreoffice/master/sal/osl/unx/mutex.c:114
#5  0xa7e5decd in acquire (this=0x9d73f1c) at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/osl/mutex.hxx:58
#6  osl::Guard<osl::Mutex>::Guard (this=0xac041e38, t=...) at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/osl/mutex.hxx:144

#7  0xa7e98894 in (anonymous namespace)::SlideShowImpl::displaySlide (this=0x9d73f18, xSlide=
    uno::Reference to {<com::sun::star::drawing::XShapes> = {<com::sun::star::container::XIndexAccess> = {<com::sun::star::container::XElementAccess> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xae7c1e00}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, xDrawPages=uno::Reference to {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xae7c0408}, <No data fields>}, xRootNode=
    uno::Reference to {<com::sun::star::container::XChild> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xa7bdce48}, <No data fields>}, <No data fields>}, rProperties=uno::Sequence of length 1 = {...})
    at /data/opt/libreoffice/master/slideshow/source/engine/slideshowimpl.cxx:1075
#8  0xae4886ed in sd::AnimationSlideController::displayCurrentSlide (this=0x9d65a30, xShow=warning: RTTI symbol not found for class 'comphelper::service_decl::detail::ServiceImpl<(anonymous namespace)::SlideShowImpl>'
    uno::Reference to {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xa7f59fac}, <No data fields>}, xDrawPages=
    uno::Reference to {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xae7c0408}, <No data fields>}, bSkipAllMainSequenceEffects=
    false) at /data/opt/libreoffice/master/sd/source/ui/slideshow/slideshowimpl.cxx:502
#9  0xae489f8a in sd::SlideshowImpl::displayCurrentSlide (this=0x9d64aa8, bSkipAllMainSequenceEffects=false)
    at /data/opt/libreoffice/master/sd/source/ui/slideshow/slideshowimpl.cxx:1416
#10 0xae48a5ad in sd::SlideshowImpl::gotoSlideIndex (this=0x9d64aa8, nIndex=5)
    at /data/opt/libreoffice/master/sd/source/ui/slideshow/slideshowimpl.cxx:3385
#11 0xae5b13f6 in sd::Receiver::parseCommand (this=0xac042120, aCommand=...)
    at /data/opt/libreoffice/master/sd/source/ui/remotecontrol/Receiver.cxx:75
#12 0xae5ac54a in sd::Communicator::execute (this=0x9231470) at /data/opt/libreoffice/master/sd/source/ui/remotecontrol/Communicator.cxx:82
#13 0xb79c00aa in salhelper::Thread::run (this=0x9231470) at /data/opt/libreoffice/master/salhelper/source/thread.cxx:60
#14 0xb79c02bd in osl::threadFunc (param=0x9231478) at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/osl/thread.hxx:187
#15 0xb7f9c89e in osl_thread_start_Impl (pData=0x9d066e0) at /data/opt/libreoffice/master/sal/osl/unx/thread.c:252
#16 0xb7c44a7d in start_thread (arg=0xac042b70) at pthread_create.c:301
#17 0xb7d2eabe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133

Where the problem is:

void SlideShowImpl::displaySlide(
    uno::Reference<drawing::XDrawPage> const& xSlide,
    uno::Reference<drawing::XDrawPagesSupplier> const& xDrawPages,
    uno::Reference<animations::XAnimationNode> const& xRootNode,
    uno::Sequence<beans::PropertyValue> const& rProperties )
    throw (uno::RuntimeException)
{
    osl::MutexGuard const guard( m_aMutex );

    if (isDisposed())
        return;

    maEffectRewinder.setRootAnimationNode(xRootNode);

    // precondition: must only be called from the main thread!
    DBG_TESTSOLARMUTEX();

So - the SolarMutex has to be taken before the m_aMutex (it seems). Unfortunately thread one is doing:

<canvas taking solar mutex>
...
#27 show (bSlideBackgoundPainted=false, this=0x9c68130) at /data/opt/libreoffice/master/slideshow/source/engine/slide/slideimpl.cxx:505
#28 slideshow::internal::(anonymous namespace)::SlideImpl::show (this=0x9c68130, bSlideBackgoundPainted=false)
---Type <return> to continue, or q <return> to quit---
    at /data/opt/libreoffice/master/slideshow/source/engine/slide/slideimpl.cxx:465
#29 0xa7e9411f in (anonymous namespace)::SlideShowImpl::notifySlideTransitionEnded (this=0x9d73f18, bPaintSlide=true)
    at /data/opt/libreoffice/master/slideshow/source/engine/slideshowimpl.cxx:2146
#30 0xa7e92d53 in operator() (a1=true, p=<optimized out>, this=<optimized out>)
    at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/external/boost/bind/mem_fn_template.hpp:165
#31 operator()<boost::_mfi::mf1<void, {anonymous}::SlideShowImpl, bool>, boost::_bi::list0> (f=<optimized out>, this=<optimized out>, 
    a=<optimized out>) at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/external/boost/bind/bind.hpp:313
#32 operator() (this=<optimized out>) at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/external/boost/bind/bind_template.hpp:20
#33 boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf1<void, {anonymous}::SlideShowImpl, bool>, boost::_bi::list2<boost::_bi::value<{anonymous}::SlideShowImpl*>, boost::_bi::value<bool> > >, void>::invoke(boost::detail::function::function_buffer &) (function_obj_ptr=...) at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/external/boost/function/function_template.hpp:153
#34 0xa7e5712d in operator() (this=<optimized out>)
    at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/external/boost/function/function_template.hpp:1013
#35 fire (this=0xa265758) at /data/opt/libreoffice/master/slideshow/source/engine/delayevent.cxx:32
#36 slideshow::internal::Delay::fire (this=0xa265758) at /data/opt/libreoffice/master/slideshow/source/engine/delayevent.cxx:27
#37 0xa7e6500f in slideshow::internal::EventQueue::process_ (this=0x9d73fec, bFireAllEvents=false)
    at /data/opt/libreoffice/master/slideshow/source/engine/eventqueue.cxx:225
#38 0xa7e6511d in slideshow::internal::EventQueue::process (this=0x9d73fec)
    at /data/opt/libreoffice/master/slideshow/source/engine/eventqueue.cxx:167
#39 0xa7e94242 in (anonymous namespace)::SlideShowImpl::update (this=0x9d73f18, nNextTimeout=@0xbfffe880)
    at /data/opt/libreoffice/master/slideshow/source/engine/slideshowimpl.cxx:2012
#40 0xae486295 in sd::SlideshowImpl::updateSlideShow (this=0x9d64aa8)
    at /data/opt/libreoffice/master/sd/source/ui/slideshow/slideshowimpl.cxx:1888
#41 0xae486489 in sd::SlideshowImpl::PostYieldListener (this=0x9d64aa8)
    at /data/opt/libreoffice/master/sd/source/ui/slideshow/slideshowimpl.cxx:1863
#42 0xb67fccb9 in Link::Call (this=0x8ac1868, pCaller=0x0) at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/tools/link.hxx:123
#43 0xb67fcb7c in VclEventListeners2::callListeners (this=0x9db40f0, i_pEvent=0x0)
    at /data/opt/libreoffice/master/vcl/source/app/vclevent.cxx:154

Frame #29 appears to hold the local mutex over the event notification (which seems like a bad idea to me in general). I suspect we're missing a reset there - will test in a bit ...
Comment 1 Michael Meeks 2013-01-26 11:45:58 UTC
By holding a reference on the slideshowimpl - perhaps we can release the m_aMutex guard before this notification (of course, there are a good dozen other identical problems in there). Whether this will again cause more deadlocks in the eventmultiplexer.cxx magic which looks like it may cleverly hold yet-another mutex while notifying.

diff --git a/slideshow/source/engine/slideshowimpl.cxx b/slideshow/source/engine/slideshowimpl.cxx
index cf672ae..d3cdbbe 100644
--- a/slideshow/source/engine/slideshowimpl.cxx
+++ b/slideshow/source/engine/slideshowimpl.cxx
@@ -2131,7 +2131,7 @@ sal_Bool SlideShowImpl::update( double & nNextTimeout )
 
 void SlideShowImpl::notifySlideTransitionEnded( bool bPaintSlide )
 {
-    osl::MutexGuard const guard( m_aMutex );
+    osl::ResettableMutexGuard guard( m_aMutex );
 
     OSL_ENSURE( !isDisposed(), "### already disposed!" );
     OSL_ENSURE( mpCurrentSlide,
@@ -2144,6 +2144,10 @@ void SlideShowImpl::notifySlideTransitionEnded( bool bPaintSlide )
         // the chance to register SlideStartEvents
         const bool bBackgroundLayerRendered( !bPaintSlide );
         mpCurrentSlide->show( bBackgroundLayerRendered );
+
+        uno::Reference<presentation::XSlideShow> xThis(
+                static_cast< presentation::XSlideShow * >( this ), uno::UNO_QUERY_THROW );
+        guard.reset(); // unlock
         maEventMultiplexer.notifySlideStartEvent();
     }
 }


Failing that - giving up all this pretense of multi-threaded-ness, and using an 'idle handler' (or ultra-short-timeout) to push the 'next slide' message to the main thread is prolly the more foolproof approach.

#9  0xae489f8a in sd::SlideshowImpl::displayCurrentSlide (this=0x9d64aa8, bSkipAllMainSequenceEffects=false)
    at /data/opt/libreoffice/master/sd/source/ui/slideshow/slideshowimpl.cxx:1416
#10 0xae48a5ad in sd::SlideshowImpl::gotoSlideIndex (this=0x9d64aa8, nIndex=5)
    at /data/opt/libreoffice/master/sd/source/ui/slideshow/slideshowimpl.cxx:3385
#11 0xae5b13f6 in sd::Receiver::parseCommand (this=0xac042120, aCommand=...)
    at /data/opt/libreoffice/master/sd/source/ui/remotecontrol/Receiver.cxx:75
#12 0xae5ac54a in sd::Communicator::execute (this=0x9231470) at /data/opt/libreoffice/master/sd/source/ui/remotecontrol/Communicator.cxx:82

ie. undoing the erroneous assumption that UNO can in general be used from multiple threads safely. [ Of course, we may need to re-think the slide thumbnailing that I also see in my backtrace here too ].

Stephan - thoughts ? [ for 4.0.0 ].
Comment 2 Michael Meeks 2013-01-26 11:46:27 UTC
Created attachment 73680 [details]
stack traces for all frames
Comment 3 Michael Meeks 2013-01-28 09:08:53 UTC
I have a simple fix that pushes the handling of all the incoming msgs into the main-thread - which solves the issue. Unfortunately we still get nasty multi-threading corruption it seems either the Canvas or the slideshow gubbins also fails to take the solar mutex at the right times.

Thread 1:
    at /data/opt/libreoffice/master/vcl/generic/glyphs/gcach_layout.cxx:407
#8  0xb6a41774 in ServerFontLayout::LayoutText (this=0x9c63228, rArgs=...)
    at /data/opt/libreoffice/master/vcl/generic/glyphs/gcach_layout.cxx:55
#9  0xb690f820 in OutputDevice::ImplLayout (this=0x9c8fb10, rOrigStr="LibreOffice Release Schedule", nMinIndex=0, nLen=<optimized out>, 
    rLogicalPos=Point = {...}, nLogicalWidth=0, pDXArray=0x9a3e920, bFilter=true)
    at /data/opt/libreoffice/master/vcl/source/gdi/outdev3.cxx:6137
#10 0xb69109b4 in OutputDevice::GetSysTextLayoutData (this=0x9c8fb10, rStartPt=Point = {...}, rStr="LibreOffice Release Schedule", nIndex=0, 
    nLen=28, pDXAry=0x9a3e920) at /data/opt/libreoffice/master/vcl/source/gdi/outdev3.cxx:7536
#11 0xaa197686 in cairocanvas::TextLayout::draw (this=0xb0b5c320, pSurface=boost::shared_ptr {_vptr.Surface = 0xaa1dcd10}, rOutDev=..., 
---Type <return> to continue, or q <return> to quit---
    rOutpos=Point = {...}, viewState=..., renderState=...) at /data/opt/libreoffice/master/canvas/source/cairo/cairo_textlayout.cxx:368
#12 0xaa18b14e in cairocanvas::CanvasHelper::drawTextLayout (this=0xa9bc718c, pOwner=0xa9bc7174, xLayoutedText=
    uno::Reference to {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xaa1dca50}, <No data fields>}, viewState=..., renderState=...)
    at /data/opt/libreoffice/master/canvas/source/cairo/cairo_canvashelper_text.cxx:375
#13 0xaa17e483 in canvas::CanvasBase<cairocanvas::CanvasBitmapSpriteSurface_Base, cairocanvas::CanvasHelper, osl::Guard<osl::Mutex>, cppu::OWeakObject>::drawTextLayout (this=0xa9bc714c, layoutetText=
    uno::Reference to {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0xaa1dca50}, <No data fields>}, viewState=..., renderState=...)
    at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/canvas/base/canvasbase.hxx:414
#14 0xb4688db7 in cppcanvas::internal::(anonymous namespace)::TextArrayAction::render (this=0x9cde640, rTransformation=...)
    at /data/opt/libreoffice/master/cppcanvas/source/mtfrenderer/textaction.cxx:1112
#15 0xb4677d20 in operator() (rAction=<optimized out>, this=0xbfffe24c)
    at /data/opt/libreoffice/master/cppcanvas/source/mtfrenderer/implrenderer.cxx:2718
#16 for_each<__gnu_cxx::__normal_iterator<const cppcanvas::internal::ImplRenderer::MtfAction*, std::vector<cppcanvas::internal::ImplRenderer::MtfAction> >, cppcanvas::internal::{anonymous}::ActionRenderer> (__f=access outside bounds of object referenced via synthetic pointer
) at /usr/include/c++/4.6/bits/stl_algo.h:4379
#17 cppcanvas::internal::ImplRenderer::draw (this=0x9c12630) at /data/opt/libreoffice/master/cppcanvas/source/mtfrenderer/implrenderer.cxx:3146
#18 0xad58a21c in slideshow::internal::ViewShape::draw (this=0x8e13b18, rDestinationCanvas=boost::shared_ptr {_vptr.Canvas = 0xb46adc78}, rMtf=
    boost::shared_ptr {_vptr.GDIMetaFile = 0xb6c47750, aList = {<std::_Vector_base<MetaAction*, std::allocator<MetaAction*> >> = {_M_impl = {<std::allocator<MetaAction*>> = {<__gnu_cxx::new_allocator<MetaAction*>> = {<No data fields>}, <No data fields>}, _M_start = 0x9cc5df0, _M_finish = 0x9cc5e94, _M_end_of_storage = 0x9cc5ef0}}, <No data fields>}, nCurrentActionElement = 40, aPrefMapMode = {mpImplMapMode = 0x9d1e7d0}, aPrefSize = Size = {width = 23023, height = 3507}, aHookHdlLink = {pInst = 0x0, pFunc = 0}, pPrev = 0x0, pNext = 0x0, pOutDev = 0x0, bPause = 0 '\000', bRecord = 0 '\000', bUseCanvas = 0 '\000'}, rAttr=empty boost::shared_ptr, rTransform=..., pClip=0x0, rSubsets=...)
    at /data/opt/libreoffice/master/slideshow/source/engine/shapes/viewshape.cxx:233

vs. Thread 22 - trying to render a preview:

    at cairo-surface.c:2625
#11 _cairo_surface_show_text_glyphs (surface=0x99427f0, op=CAIRO_OPERATOR_OVER, source=0xab2d4444, utf8=0x0, utf8_len=0, glyphs=0xab2d3c4c, 
    num_glyphs=40, clusters=0xab2d344c, num_clusters=0, cluster_flags=0, scaled_font=0x94b0d18, clip=0xab2d4524) at cairo-surface.c:2552
#12 0xb50bbdd0 in _cairo_gstate_show_text_glyphs (gstate=0x9c62d70, utf8=0x0, utf8_len=0, glyphs=0x9bb6a00, num_glyphs=40, clusters=0x0, 
    num_clusters=<optimized out>, cluster_flags=0) at cairo-gstate.c:1981
#13 0xb50b11ed in cairo_show_glyphs (num_glyphs=40, glyphs=0x9bb6a00, cr=0x9c62d50) at cairo.c:3509
#14 cairo_show_glyphs (cr=0x9c62d50, glyphs=0x9bb6a00, num_glyphs=40) at cairo.c:3489
#15 0xb23a3aae in X11SalGraphics::DrawServerFontLayout (this=0x9c22c68, rLayout=...)
    at /data/opt/libreoffice/master/vcl/unx/generic/gdi/salgdi3.cxx:465
#16 0xb6a4138d in ServerFontLayout::DrawText (this=0x9810620, rSalGraphics=...)
    at /data/opt/libreoffice/master/vcl/generic/glyphs/gcach_layout.cxx:46
#17 0xb69125d0 in OutputDevice::ImplDrawTextDirect (this=0x9822d18, rSalLayout=..., bTextLines=0 '\000')
    at /data/opt/libreoffice/master/vcl/source/gdi/outdev3.cxx:4735
#18 0xb6912bd0 in ImplDrawText (rSalLayout=..., this=0x9822d18) at /data/opt/libreoffice/master/vcl/source/gdi/outdev3.cxx:4890
#19 OutputDevice::ImplDrawText (this=0x9822d18, rSalLayout=...) at /data/opt/libreoffice/master/vcl/source/gdi/outdev3.cxx:4873
#20 0xb69136e6 in OutputDevice::DrawTextArray (this=0x9822d18, rStartPt=Point = {...}, 
    rStr="Future / research pipeline ...\001(or some things we're slowly working on)", pDXAry=0x97a48e0, nIndex=31, nLen=40)
    at /data/opt/libreoffice/master/vcl/source/gdi/outdev3.cxx:5786

full trace to follow.
Comment 4 Michael Meeks 2013-01-28 09:17:17 UTC
Created attachment 73761 [details]
second silly threading UNO threading issue exposed.
Comment 5 Not Assigned 2013-01-28 10:29:49 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=58b05ce98e72fe47bdca02d2dabea20c36a494bf

fdo#59881 - sdremote: give up on threaded / UNO usage.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 6 Stephan Bergmann 2013-01-28 14:20:33 UTC
(In reply to comment #1)
> Stephan - thoughts ?

It is known that LO still contains code that is likely not threading-safe, but that nevertheless gets used in multi-threaded scenarios; this is not necessarily related to anything UNO.  In particular, calling event notification callbacks with a private mutex locked is indeed bad.

The "canonical" fix for the given case would be to dispatch events into the VCL event loop from sd::Communicator::execute, instead of going via a timer, though, I would assume.
Comment 7 Not Assigned 2013-01-28 16:35:39 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f07efaa3bbeb6c2160d6ccbe83ea4183df7115a3&h=libreoffice-4-0

fdo#59881 - sdremote: give up on threaded / UNO usage.


It will be available in LibreOffice 4.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 8 Stephan Bergmann 2013-01-28 17:14:08 UTC
A potential problem with the changes of <http://cgit.freedesktop.org/libreoffice/core/commit/?id=58b05ce98e72fe47bdca02d2dabea20c36a494bf> "fdo#59881 - sdremote: give up on threaded / UNO usage" to SlideShowImpl::notifySlideTransitionEnded (slideshow/source/engine/slideshowimpl.cxx) is that maEventMultiplexer.notifySlideStartEvent() is now called un-guarded while there are other (guarded) calls in SlideShowImpl::disposing that modify maEventMultiplexer (maEventMultiplexer.remove...(...), maEventMultiplexer.clear()), which could lead to races.  (Also, other places in that file still call maEventMultiplexer notification functions with the guard locked, anyway.)
Comment 9 Michael Meeks 2013-01-29 00:26:26 UTC
> A potential problem with the changes 
> /slideshowimpl.cxx) is that maEventMultiplexer.notifySlideStartEvent()
> is now called un-guarded

Oh - wow, that was silly - quite right; I didn't want to do that - just to shunt everything into the mainloop is fix enough, and that is potentially dangerous.

Thanks for the review !
Comment 10 Not Assigned 2013-01-29 00:42:06 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ab8e37573628f2e5863e7fc0252103ab32203fc2

fdo#59881 - sdremote: revert un-necessary locking change.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 11 Not Assigned 2013-01-29 08:58:55 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b696a67f92c7206fe947996931995a70229752e&h=libreoffice-4-0

fdo#59881 - sdremote: revert un-necessary locking change.


It will be available in LibreOffice 4.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 12 Not Assigned 2013-01-29 09:46:49 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-0-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dad7a304cbf58d24180e57091140b9f53a48a9b9&h=libreoffice-4-0-0

fdo#59881 - sdremote: give up on threaded / UNO usage.


It will be available already in LibreOffice 4.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 Michael Meeks 2013-01-29 11:50:55 UTC
Patch(es) in libreoffice-4-0-0 look fine => closing.