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

On 12/01/12 14:44, Stephan Bergmann wrote:
> I added a new tinderbox "Linux-RHEL6-x86_64-check" to 
> <http://tinderbox.libreoffice.org/MASTER/status.html> (and it will spam 
> suspects with messages about failing builds in the usual way).
>
> The box does a rather complete build (--enable-binfilter, no 
> --with-system switches) and especially enables the debug features 
> --enable-dbgutil and --enable-werror.  Additionally, it calls tinbuild2 
> with -t switch, i.e., it runs all the subsequent tests via a toplevel 
> "make check".  The turnaround time is approximately four hours.

great news!

> The other is a sporadic failure of forms_unoapi, an soffice.bin crash 
> somewhere underneath
>
> > [...]
> > #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...

but if that's the only problem we have, then you must have fixed quite a
few bugs :)