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

On 13/01/12 15:14, Stephan Bergmann wrote:
> On 01/12/2012 02:52 PM, Michael Stahl wrote:
> > On 12/01/12 14:44, Stephan Bergmann wrote:
> > > > #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
> > > > [...]
> > >
> > > on the main thread while an URP thread is simultaneously executing
> > > SwXTextDocument::close.  Looks like SwXTextDocument::close destroys data
> > > that is still accessed within SwEditWin::Paint, but I haven't yet come
> > > around to find the cause here.  (Problem can only be observed
> > > sporadically, and valgrind didn't help yet.)  I plan to follow up on
> > > this, however.  Please ignore tinderbox failure mails that are due to
> > > this crash in the meantime.
> >
> > sounds bad; that looks like a SolarMutex guard is missing somewhere...
>
> 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...