| Summary: | vcl: mac progress bar rendering infinite recursion | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Michael Meeks <michael.meeks> |
| Component: | LibreOffice | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caolan.mcnamara, michael.meeks, nthiebaud, sberg.fun, thb |
| Priority: | medium | Keywords: | regression |
| Version: | 4.0.0.0.alpha1 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
FYI, I cannot reproduce with my own recent master builds on a Mac OS X 10.7 box. Thanks Stephan - perhaps it depends on theme or something (?) I assume the issue is:
while( pEraseWindow->IsPaintTransparent()
is set on the window but only in some corner cases - but - perhaps I'm wrong.
I can't see a way not to hit the recursion otherwise if we make it to that path :-)
Caolan, there is some thought it might be related to: http://cgit.freedesktop.org/libreoffice/core/commit/?id=a0a5eed63b871e2febb36e27e9dea4b7e57f681b Thorsten - it was your mac that this reproduced on - can you help sub-set the problem ? Neither Norbert nor Stephan can reproduce it. Can't easily build on that box, and currently blocked on bluetooth impl - gladly try any available test binaries though. I had a mac build that crashed on installing an extension, re-pulled and rebuilt and it doesn't crash for me now. There have been two follow up commits to that make-containers-transparent thing (if its related) So - nominally fixed; though I can't see how that mac code path could ever work personally ;-) it'd be nice to verify that on your machine Thorsten with a 4.0 beta build / download as/when :-) |
Installing a Java extension on a master snapshot on mac gives rather a fun infinite recursion crash: ... Window::Update DrawProgress ProgressBar::ImplDrawProgress ProgressBar::Paint Window::ImplCallPaint ... lots of same ... Window::Update ... loop etc. until crash. Reading the code it is amazing that we have: bool bNeedErase = ImplGetSVData()->maNWFData.mbProgressNeedsErase; ... if( bNeedErase ) { Window* pEraseWindow = pWindow; while( pEraseWindow->IsPaintTransparent() && ! pEraseWindow->ImplGetWindowImpl()->mbFrame ) { pEraseWindow = pEraseWindow->ImplGetWindowImpl()->mpParent; } if( pEraseWindow == pWindow ) // restore background of pWindow pEraseWindow->Erase( rFramePosSize ); else { // restore transparent background Point aTL( pWindow->OutputToAbsoluteScreenPixel( rFramePosSize.TopLeft() ) ); aTL = pEraseWindow->AbsoluteScreenToOutputPixel( aTL ); Rectangle aRect( aTL, rFramePosSize.GetSize() ); pEraseWindow->Invalidate( aRect, INVALIDATE_NOCHILDREN | INVALIDATE_NOCLIPCHILDREN | INVALIDATE_TRANSPARENT ); pEraseWindow->Update(); } pWindow->Push( PUSH_CLIPREGION ); pWindow->IntersectClipRegion( rFramePosSize ); So - I think the '// restore transparent background' section is totally bonkers. How can that ever have worked ? I can only conclude that it didn't and that this path was not called. Comparing with similar code in button.cxx: void CheckBox::ImplInvalidateOrDrawCheckBoxState() { if( ImplGetSVData()->maNWFData.mbCheckBoxNeedsErase ) Similar erase / invalidation is done but never in the paint method itself.