Issue 101209 - Crash (memory full) after undo of moving linked frame
Summary: Crash (memory full) after undo of moving linked frame
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: OOO310m9
Hardware: All All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-20 07:19 UTC by Joe Smith
Modified: 2017-05-20 10:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Joe Smith 2009-04-20 07:19:12 UTC 
*Caution*
This may cause OOo to consume all system memory, which can cause other
applications to halt or crash, or possibly a system crash.

Steps to reproduce:
1) Open the document attached to issue 101115:
http://www.openoffice.org/nonav/issues/showattachment.cgi/61675/Writer_moving_frames.odt
2) Select the lower frame on page one
3) Drag the frame onto page 3
4) Edit > Undo

OOo will rapidly consume all available memory (2G+2G swap in ~15s on my system).

This happens with:
  3.1   [310m9(Build:9396)]
  3.0.1 [300m15(Build:9379)]
  2.4.2 [680m18(Build:9364)]

running on Fedora Linux 9 (i686/athlon)
Comment 1 eric.savary 2009-04-20 08:55:53 UTC 
Cannot reproduce on Windows XP with 310m7
Comment 2 michael.ruess 2009-04-20 10:21:58 UTC 
MRU->OD: can confirm this on Windows XP, but no regression, also crashed in OOo 2.x.
Open mentioned document, move the frame lower on page one to page three (NOT
drag and drop, just move it), undo -> OOo heavily eats up memory (~ 50 MB per
second).
Comment 3 Oliver-Rainer Wittmann 2009-04-30 09:53:21 UTC 
OD->AW: Please take over.
There seems to be problem in method <basegfx::tools::applyLineDashing(..)> due
to big values of variables <fDotDashMovingLength> and <fEdgeLength>.
Comment 4 Armin Le Grand 2009-06-22 14:54:25 UTC 
AW: Problem is that a OverlayPolyPolygonStriped is used with a misshaped
Polygon; it has two points and is closed (bad enough), but the 2nd point is at
(2147463647.0000000, 2147463647.0000000) which sounds extremely like a msiplaced
point. Trying to find out who sets this...
Comment 5 Armin Le Grand 2009-07-02 16:41:00 UTC 
AW->OD: SdrDropMarkerOverlay::SdrDropMarkerOverlay is called from SW's
SwFEShell::SetChainMarker with a bad end point. The OverlayPolyPolygonStriped
does nothing wrong when decomposing this VERY long line, it simply produces too
many short snippets. I could somehow hard-code to not apply line styles to
extremely long lines, but the better fix will be to not give misplaced
coordinates to the object creation. Please find out why this wrong point is used
and use a correct one.
Comment 6 Joe Smith 2013-09-13 14:17:44 UTC 
Just tried again, testing AOO 4.0 on Fedora Linux 17: same crash, 100% cpu.
Comment 7 Joe Smith 2014-04-17 23:31:57 UTC 
Testing 4.1 beta

Same crash: 100% cpu/unresponsive. Must force quit.
Comment 8 Marcus 2017-05-20 10:45:00 UTC 
Reset the assignee to the default "issues@openoffice.apache.org".