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

[Stephan Bergmann]

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 at 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?

Stephan