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 ].

Created attachment 73680 [details]
stack traces for all frames

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.

Created attachment 73761 [details]
second silly threading UNO threading issue exposed.

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.

(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.

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.

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.)

> 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 !

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.

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.

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.

Patch(es) in libreoffice-4-0-0 look fine => closing.