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.schoenh...@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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
