Bug Hunting Session
Bug 44721 - Report builder: upon mouse-resize control, (nearly) infinite loop and memory consumption
Summary: Report builder: upon mouse-resize control, (nearly) infinite loop and memory ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.5.0 Beta3
Hardware: All All
: medium critical
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:3.7.0 target:3.5.7 target:3.6.2
Keywords: regression
: 42319 (view as bug list)
Depends on:
Blocks: 54930 54933 mab3.5 52471
  Show dependency treegraph
 
Reported: 2012-01-12 06:29 UTC by Lionel Elie Mamane
Modified: 2012-09-19 14:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
reproduction video 1 (2.37 MB, video/ogg)
2012-07-27 14:05 UTC, Lionel Elie Mamane
Details
reproduction file for video 2 (39.95 KB, application/vnd.oasis.opendocument.database)
2012-07-27 14:07 UTC, Lionel Elie Mamane
Details
reproduction video 2 (1.08 MB, video/ogg)
2012-07-27 14:21 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2012-01-12 06:29:09 UTC
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.
Comment 1 Lionel Elie Mamane 2012-02-20 09:42:45 UTC
Reconfirmed with binaries from libreoffice.org on GNU/Linux (Debian amd64) and MS Windows (32 bits).
Comment 2 andy 2012-03-19 09:43:34 UTC
Also confirmed on Linux Mint 12 amd_64.
Comment 3 Alex Thurgood 2012-03-23 03:14:01 UTC
Hmm, thought it might be time to actually confirm this ;-)

BTW, it causes a crash on Mac OSX.


Alex
Comment 4 Alex Thurgood 2012-03-23 03:24:09 UTC
(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
Comment 5 Alex Thurgood 2012-03-23 03:25:13 UTC
Lionel,

Can we consider this solved, mitigated, or worked around ?


Alex
Comment 6 tommy27 2012-05-14 15:42:48 UTC
is this 3.5.x MAB still reproducible in 3.5.3?

I cannot test since I don't know to use base.
Comment 7 Michael Meeks 2012-06-06 07:34:06 UTC
Thorsten - a basegfx crasher - any chance of a look ? :-)
Comment 8 Lionel Elie Mamane 2012-06-06 14:36:41 UTC
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...
Comment 9 Alex Thurgood 2012-06-07 01:50:37 UTC
Can not reproduce with :

LibreOffice 3.5.4.2 
Version ID : 165a79a-7059095-e13bb37-fef39a4-9503d18

on Mac OSX 10.6.8
Comment 10 Lionel Elie Mamane 2012-07-27 10:16:04 UTC
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.
Comment 11 tommy27 2012-07-27 11:38:13 UTC
(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?
Comment 12 Lionel Elie Mamane 2012-07-27 14:03:49 UTC
(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
Comment 13 Lionel Elie Mamane 2012-07-27 14:05:19 UTC
Created attachment 64780 [details]
reproduction video 1
Comment 14 Lionel Elie Mamane 2012-07-27 14:07:05 UTC
Created attachment 64781 [details]
reproduction file for video 2
Comment 15 Lionel Elie Mamane 2012-07-27 14:21:39 UTC
Created attachment 64782 [details]
reproduction video 2
Comment 16 Alex Thurgood 2012-07-27 16:11:59 UTC
*** Bug 42319 has been marked as a duplicate of this bug. ***
Comment 17 Alex Thurgood 2012-08-23 06:39:28 UTC
I can reproduce this again on Mac OSX 10.8 with LO 3.7.0 from daily master build of 21/08.


Alex
Comment 18 Thorsten Behrens (CIB) 2012-08-23 12:28:48 UTC
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.)
Comment 19 Thorsten Behrens (CIB) 2012-08-23 17:22:14 UTC
(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.
Comment 20 Not Assigned 2012-09-14 15:55:20 UTC
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.
Comment 21 Lionel Elie Mamane 2012-09-14 16:02:20 UTC
Awaiting review for backport to libreoffice-3-6 and libreoffice-3-5
Comment 22 Not Assigned 2012-09-14 16:23:15 UTC
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.
Comment 23 Not Assigned 2012-09-17 09:54:26 UTC
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.
Comment 24 Not Assigned 2012-09-17 10:00:10 UTC
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.