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

[Michael Stahl]

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 :)