Problem observed with current libreoffice-3-5, but not with libreoffice 3.4.4, on Debian GNU/Linux amd64 architecture. Reproduction instructions: Edit a report in a an .odb file. Select a control. Resize the control with the mouse. Result: LibreOffice consumes all CPU and has an ever increasing memory consumption. On GTK/X11, the mouse pointer is grabbed by LibreOffice and This makes the design (edit) view of report builder rather unusable... I traced that to the following loop in file basegfx/source/polygon/, function applyLineDashing, line 1426 while(fTools::less(fDotDashMovingLength, fEdgeLength)) { (...) aSnippet.append(interpolate(aCurrentEdge.getStartPoint(), aCurrentEdge.getEndPoint(), fDotDashMovingLength / fEdgeLength)); (...) pLineTarget->append(aSnippet); (...) aSnippet.clear(); (...) fDotDashMovingLength += rDotDashArray[(++nDotDashIndex) % nDotDashCount]; } Each execution of that loop allocates memory (the return value of interpolate, which is saved into pLineTarget or pGapTarget); this explains the ever increasing memory consumption. In the example I investigated, that loop was up for about 30,000,000 executions, because each element of rDotDashArray is about 70 and fEdgelength is 2,147,483,648, about 30,000,000 times more. If every execution consumes about 100 bytes, we are already at 3GB memory consumption before this loop finishes... This seems infinite to the user. FYI, aCurrentEdge.getStartPoint() and aCurrentEdge.getEndPoint() are (0; -2,147,483,648) and (-2,147,483,648; -2,147,483,648). I'm a bit surprised at the negative numbers, but not sure what they are supposed to mean, or in what units they are. Points? Hundredths of a millimeter? As a stopgap measure, I added if (nDotDashIndex >= 10000) break; To the end of the loop. It makes the resize slow, but works.
Reconfirmed with binaries from libreoffice.org on GNU/Linux (Debian amd64) and MS Windows (32 bits).
Also confirmed on Linux Mint 12 amd_64.
Hmm, thought it might be time to actually confirm this ;-) BTW, it causes a crash on Mac OSX. Alex
(In reply to comment #3) > Hmm, thought it might be time to actually confirm this ;-) > > BTW, it causes a crash on Mac OSX. > > > Alex Whoops, seems I can't get it to crash any more on : LibreOffice 3.5.1.2 Version ID : dc9775d-05ecbee-0851ad3-1586698-727bf66 Alex
Lionel, Can we consider this solved, mitigated, or worked around ? Alex
is this 3.5.x MAB still reproducible in 3.5.3? I cannot test since I don't know to use base.
Thorsten - a basegfx crasher - any chance of a look ? :-)
I can't reproduce now, not even with LibreOffice 3.5.0beta1 (official binaries). All this time I thought I wasn't seeing the bug because of the crude work-around applied to my development tree...
Can not reproduce with : LibreOffice 3.5.4.2 Version ID : 165a79a-7059095-e13bb37-fef39a4-9503d18 on Mac OSX 10.6.8
Dogfooding 3.6.0.rc, I get this bug *again*, but not on every mouse-resize, only on "some". I haven't yet found out exactly what triggers it, it could be an inversion (drag the upper border below the lower border). This may be related to the fact that mouse-resize and mouse-move are flaky to start with: 1) Select several controls. Go to right border on one, start moving it (press mouse button, hold and move mouse left or right). It should move the *right* border, but it moves the *left* border (!). 2) Select one control in a header. Move it down within the header. More often than not it ends up in the detail section; although the mouse pointer stays well within the header. Also see bug 52471, which looks quite similar.
(In reply to comment #9) > Can not reproduce with : > > LibreOffice 3.5.4.2 > Version ID : 165a79a-7059095-e13bb37-fef39a4-9503d18 > > on Mac OSX 10.6.8 (In reply to comment #10) > Dogfooding 3.6.0.rc, I get this bug *again*, but not on every mouse-resize, > only on "some". > ... snip ... what about 3.5.5? has the bug reappered in the latest 3.5.x release as well or just in the 3.6.x branch?
(In reply to comment #11) > (In reply to comment #10) >> Dogfooding 3.6.0.rc, I get this bug *again*, but not on every mouse-resize, >> only on "some". > what about 3.5.5? has the bug reappered in the latest 3.5.x release as well or > just in the 3.6.x branch? Yes, I get it on 3.5.5.3, too (official adm64 .deb binaries). I attach a video as demonstration. I think I'm getting the common pattern how to crash it: 1) Select a control in the header 2) Vertically resize it *above* the upper limit of the header. Because the mouse-resize does not obey the movements well, but jumps around *beyond* the mouse pointer position, this is quite easy to do by accident. 3) Resize the lower bound or lower/right corner
Created attachment 64780 [details] reproduction video 1
Created attachment 64781 [details] reproduction file for video 2
Created attachment 64782 [details] reproduction video 2
*** Bug 42319 has been marked as a duplicate of this bug. ***
I can reproduce this again on Mac OSX 10.8 with LO 3.7.0 from daily master build of 21/08. Alex
Yep, see that in master builds - though the stack is different now: #0 0x00007fffe7be1e31 in Rectangle::Rectangle (this=0x7fffffffaa00, rLT=Point = {...}, rSize=Size = {...}) at /builds/oobuild/libo-master/solver/unxlngx6.pro/inc/tools/gen.hxx:436 #1 0x00007fffe7c30ce4 in X11SalGraphics::GetGlyphBoundRect (this=0x20e3c00, nGlyphIndex=18, rRect=Rectangle = {...}) at /builds/oobuild/libo-master/vcl/unx/generic/gdi/salgdi3.cxx:704 #2 0x00007ffff2d62852 in SalLayout::GetBoundRect (this=0x21e8e50, rSalGraphics=..., rRect=Rectangle = {...}) at /builds/oobuild/libo-master/vcl/source/gdi/sallayout.cxx:760 #3 0x00007ffff2c4675a in OutputDevice::GetTextBoundRect (this=0x1de5368, rRect=Rectangle = {...}, rStr="142390", nBase=0, nIndex=0, nLen=65535, nLayoutWidth=0, pDXAry=0x0) at /builds/oobuild/libo-master/vcl/source/gdi/outdev3.cxx:7736 #4 0x00007ffff4718ccd in Ruler::ImplVDrawText (this=0x1de51a8, nX=-13669440, nY=8, rText="142390", nMin=0, nMax=162329425) at /builds/oobuild/libo-master/svtools/source/control/ruler.cxx:377 #5 0x00007ffff4719bef in Ruler::ImplDrawTicks (this=0x1de51a8, nMin=0, nMax=162329425, nStart=0, nCenter=8) at /builds/oobuild/libo-master/svtools/source/control/ruler.cxx:587 #6 0x00007ffff471c56f in Ruler::ImplFormat (this=0x1de51a8) at /builds/oobuild/libo-master/svtools/source/control/ruler.cxx:1181 #7 0x00007ffff471c992 in Ruler::ImplDraw (this=0x1de51a8) at /builds/oobuild/libo-master/svtools/source/control/ruler.cxx:1258 #8 0x00007ffff471eb54 in Ruler::Paint (this=0x1de51a8) at /builds/oobuild/libo-master/svtools/source/control/ruler.cxx:2064 (etc.)
(In reply to comment #18) > Yep, see that in master builds - though the stack is different now: > > /builds/oobuild/libo-master/svtools/source/control/ruler.cxx:377 > So, this is nothing about basegfx, but batshit-insane bounds for the rulers, and subsequently ages to paint them into some virdev. For the ruler rect, I e.g. get Size = { width = 0x12, height = 0x9acf351 } Kinda needs to be fixed at reportdesign level - I already get ridiculous values in rptui::OViewsWindow::resize.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d33453d1ca13369d9132c304c80acf19e9b1ad4e fdo#44721 protect against negative calculated height value The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Awaiting review for backport to libreoffice-3-6 and libreoffice-3-5
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bacceec11fc1e9d4999308040ae36848c24376d4&g=libreoffice-3-5 fdo#44721 protect against negative calculated height value It will be available in LibreOffice 3.5.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-6-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=517f98528e27bbecc308ad98a830fce5dca60bb3&g=libreoffice-3-6-2 fdo#44721 protect against negative calculated height value It will be available already in LibreOffice 3.6.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9d270d24de55d0f962cd3394b8ebf9d3e4622dfb&g=libreoffice-3-6 fdo#44721 protect against negative calculated height value It will be available in LibreOffice 3.6.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.