Re: [Libreoffice] New Tinderbox Linux-RHEL6-x86_64-check

On 01/13/2012 05:42 PM, Stephan Bergmann wrote:
> On 01/13/2012 03:33 PM, Michael Stahl wrote:
> > On 13/01/12 15:14, Stephan Bergmann wrote:
> > > Given that SwXTextDocument::close is just
> > >
> > > > void SwXTextDocument::close( sal_Bool bDeliverOwnership ) throw(
> > > > util::CloseVetoException, RuntimeException )
> > > > {
> > > > if(IsValid()&& m_pHiddenViewFrame)
> > > > lcl_DisposeView( m_pHiddenViewFrame, pDocShell);
> > > > SfxBaseModel::close(bDeliverOwnership);
> > > > }
> > >
> > > and that SfxBaseModel::close has its complete body protected by a
> > > SolarMutexGuard, would including the first two lines of close's body in
> > > the guarded region (or spanning an additional region around just part of
> > > that) look correct?
> >
> > i already have a patch to do that, but i'm afraid that it won't help
> > because when i run forms_unoapi lcl_DisposeView is never called (and
> > IsValid just reads a boolean member, that is unlikely to cause trouble).
> >
> > also, when the main thread fires its timer it has the SolarMutex locked
> > in (i don't have the stack anymore) SalInstance::Yield or something like
> > that.
> >
> > so it doesn't seem to be anything obvious...
>
> Ha, one of the crashes that I saved finally gives it away:
>
> > Thread 1:
> > #0 in com::sun::star::uno::BaseReference::is at
> > solver/unxlngx6/inc/com/sun/star/uno/Reference.h:103
> > #1 in sdr::contact::ControlHolder::is at
> > svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:204
> > #2 in sdr::contact::ViewObjectContactOfUnoControl_Impl::hasControl at
> > svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:642
> > #3 in sdr::contact::ViewObjectContactOfUnoControl::isPrimitiveVisible
> > at svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:1815
> > #4 in sdr::contact::ViewObjectContact::getPrimitive2DSequenceHierarchy
> > at svx/source/sdr/contact/viewobjectcontact.cxx:396
> > #5 in
> > sdr::contact::ViewObjectContact::getPrimitive2DSequenceSubHierarchy at
> > svx/source/sdr/contact/viewobjectcontact.cxx:428
> > #6 in
> > sdr::contact::ViewObjectContactOfPageHierarchy::getPrimitive2DSequenceHierarchy
> > at svx/source/sdr/contact/viewobjectcontactofsdrpage.cxx:450
> > #7 in
> > sdr::contact::ViewObjectContact::getPrimitive2DSequenceSubHierarchy at
> > svx/source/sdr/contact/viewobjectcontact.cxx:428
> > #8 in
> > sdr::contact::ViewObjectContactOfSdrPage::getPrimitive2DSequenceHierarchy
> > at svx/source/sdr/contact/viewobjectcontactofsdrpage.cxx:699
> > #9 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay at
> > svx/source/sdr/contact/objectcontactofpageview.cxx:248
> > #10 in sdr::contact::ObjectContactOfPageView::ProcessDisplay at
> > svx/source/sdr/contact/objectcontactofpageview.cxx:132
> > #11 in SdrPageWindow::RedrawLayer at
> > svx/source/svdraw/sdrpagewindow.cxx:391
> > #12 in SdrPageView::DrawLayer at svx/source/svdraw/svdpagv.cxx:398
> > #13 in SwViewImp::PaintLayer at sw/source/core/view/vdraw.cxx:148
> > #14 in SwRootFrm::Paint at sw/source/core/layout/paintfrm.cxx:2976
> > #15 in ViewShell::Paint at sw/source/core/view/viewsh.cxx:1678
> > #16 in SwCrsrShell::Paint at sw/source/core/crsr/crsrsh.cxx:1165
> > #17 in SwEditWin::Paint at sw/source/ui/docvw/edtwin2.cxx:535
> > #18 in Window::ImplCallPaint at vcl/source/window/window.cxx:2417
> > #19 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
> > #20 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
> > #21 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
> > #22 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
> > #23 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
> > #24 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
> > #25 in Window::ImplCallOverlapPaint at vcl/source/window/window.cxx:2477
> > #26 in Window::ImplHandlePaintHdl at vcl/source/window/window.cxx:2497
> > #27 in Window::LinkStubImplHandlePaintHdl at
> > vcl/source/window/window.cxx:2491
> > #28 in Link::Call at solver/unxlngx6/inc/tools/link.hxx:140
> > #29 in Timer::Timeout at vcl/source/app/timer.cxx:256
> > #30 in Timer::ImplTimerCallbackProc at vcl/source/app/timer.cxx:144
> > #31 in SalTimer::CallCallback at vcl/inc/saltimer.hxx:66
> > #32 in SvpSalInstance::CheckTimeout at vcl/headless/svpinst.cxx:199
> > #33 in SvpSalInstance::Yield at vcl/headless/svpinst.cxx:310
> > #34 in ImplYield at vcl/source/app/svapp.cxx:455
> > #35 in Application::Reschedule at vcl/source/app/svapp.cxx:482
> > #36 in SolarMutexReleaser::~SolarMutexReleaser at
> > solver/unxlngx6/inc/vcl/svapp.hxx:551
> > #37 in VCLXWindowImpl::OnProcessCallbacks at
> > toolkit/source/awt/vclxwindow.cxx:320
> > #38 in VCLXWindowImpl::LinkStubOnProcessCallbacks at
> > toolkit/source/awt/vclxwindow.cxx:291
> > #39 in Link::Call at solver/unxlngx6/inc/tools/link.hxx:140
> > #40 in ImplHandleUserEvent at vcl/source/window/winproc.cxx:1999
> > #41 in ImplWindowFrameProc at vcl/source/window/winproc.cxx:2571
> > #42 in SalFrame::CallCallback at vcl/inc/salframe.hxx:294
> > #43 in SvpSalInstance::Yield at vcl/headless/svpinst.cxx:299
> > #44 in ImplYield at vcl/source/app/svapp.cxx:455
> > #45 in Application::Yield at vcl/source/app/svapp.cxx:489
> > #46 in Application::Execute at vcl/source/app/svapp.cxx:432
> > #47 in desktop::Desktop::Main at desktop/source/app/app.cxx:1824
> > #48 in ImplSVMain at vcl/source/app/svmain.cxx:178
> > #49 in SVMain at vcl/source/app/svmain.cxx:215
> > #50 in soffice_main at desktop/source/app/sofficemain.cxx:67
> > #51 in sal_main at desktop/source/app/main.c:34
> > #52 in main at desktop/source/app/main.c:33
> >
> > Thread 10:
> > #0 __lll_unlock_wake at
> > ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:373
> > #1 in _L_unlock_657 from /lib64/libpthread-2.12.so
> > #2 in __pthread_mutex_unlock_usercnt at pthread_mutex_unlock.c:52
> > #3 __pthread_mutex_unlock at pthread_mutex_unlock.c:290
> > #4 in osl_releaseMutex at sal/osl/unx/mutex.c:179
> > #5 in vcl::SolarMutexObject::release at vcl/source/app/solarmutex.cxx:54
> > #6 in SalYieldMutex::release at vcl/generic/app/geninst.cxx:73
> > #7 in SolarMutexGuard::~SolarMutexGuard at
> > solver/unxlngx6/inc/vcl/svapp.hxx:436
> > #8 in SfxBaseModel::close at sfx2/source/doc/sfxbasemodel.cxx:1500
> > #9 in SwXTextDocument::close at sw/source/ui/uno/unotxdoc.cxx:574
> > #10 in callVirtualMethod at
> > bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:155
> > #11 in cpp_call at
> > bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:392
> > #12 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch at
> > bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:586
> > #13 in binaryurp::IncomingRequest::execute_throw at
> > binaryurp/source/incomingrequest.cxx:263
> > #14 in binaryurp::IncomingRequest::execute at
> > binaryurp/source/incomingrequest.cxx:89
> > #15 in binaryurp::(anonymous namespace)::request at
> > binaryurp/source/reader.cxx:107
> > #16 in cppu_threadpool::JobQueue::enter at
> > cppu/source/threadpool/jobqueue.cxx:121
> > #17 in cppu_threadpool::ORequestThread::run at
> > cppu/source/threadpool/thread.cxx:222
> > #18 in cppu_requestThreadWorker at cppu/source/threadpool/thread.cxx:57
> > #19 in osl_thread_start_Impl at sal/osl/unx/thread.c:292
> > #20 in start_thread at pthread_create.c:301
> > #21 in clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
>
> (Note that thread 10 calling SwXTextDocument::close is right at the end
> of SfxBaseModel::close already, so covering the first part of
> SwXTextDocment::close by solar mutex would indeed not have made a
> difference here -- though it still should be decided if that's generally
> needed I guess?)
>
> The culprit is VCLXWindowImpl::OnProcessCallbacks (frame 37 of thread
> 1): It calls SolarMutexReleaser with RescheduleDuringAcquire, so that
> Application::Reschedule is called with unlocked solar mutex.
> SvpSalInstance::Yield (frame 33) calls ReleaseYieldMutex followed by
> AcquireYieldMutex before calling into SvpSalInstance::CheckTimeout (and
> "yield mutex" and "solar mutex" are the same thing). But if the solar
> mutex is unacquired upon entry to SvpSalInstance::Yield,
> ReleaseYieldMutex/AcquireYieldMutex will still leave it unacquired...
>
> Adding the ReleaseSolarMutex to VCLXWndowImpl::OnProcessCallbacks was
> done in OOo as
>
> > changeset: 272099:090be202635a
> > user: Frank Schoenheit [fs] <frank.schoenheit@oracle.com>
> > date: Fri Sep 03 17:26:50 2010 +0200
> > summary: dba33i: #163542# VCLXWindow::OnProcessCallbacks: process
> > window events while attempting to re-acquire the solar mutex - this
> > prevents deadlocks with other threads trying to SendMessage into the
> > main thread
>
> The question is where to put an additional acquire of the solar mutex --
> into Application::Reschedule (or would that be too broad? also,
> SolarMutexReleaser(RescheduleDuringAcquire) would become rather useless
> then), into SvpSalInstance::Yield (and then it would need to go into the
> other SalInstance::Yield derivations, too), into
> Window::LinkStubImplHandlePaintHdl (but then it would need to go into
> all and every function that can be called from the event loop?), into
> ..., or is Frank's fix not good after all?

Seeing that the above changeset (that contains the only use of 
RescheduleDuringAcquire) is also the changeset that introduced that 
feature, but fails to give any hint what those deadlocks look like (and 
the cited HH internal issue 163542 is not available for inspection), I 
have now reverted that strange feature as 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=1ef1781390845d03b6e1518bbac81b818be62f3d>. 
 If deadlocks should resurface, lets see how to fix them cleanly.

Stephan