Summary: | Report builder: upon mouse-resize control, (nearly) infinite loop and memory consumption | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Lionel Elie Mamane <lionel> |
Component: | Base | Assignee: | Lionel Elie Mamane <lionel> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | iplaw67, michael.meeks, spamfilter, thb |
Priority: | medium | Keywords: | regression |
Version: | 3.5.0 Beta3 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | target:3.7.0 target:3.5.7 target:3.6.2 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 54930, 54933, 37361, 52471 | ||
Attachments: |
reproduction video 1
reproduction file for video 2 reproduction video 2 |
Description
Lionel Elie Mamane
2012-01-12 06:29:09 UTC
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. |