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

[Michael Stahl]

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