Opening attached .sdd/.odp file freezes LibreOffice 3.6.2.2 as well as 4.0. LibreOffice takes 100% of RAM and never ends. The LibreOffice process must be killed. CPU usage is allthroughout normal. How to reproduce: * Just open the .odp file in LibreOffice. It will freeze. In case you use a version <4.0, you can also try the .sdd file. LO will freeze. System: Ubuntu 12.10 P.S. The .sdd file is the original file. I converted it to .odp via "libreoffice --headless --convert-to odp *.sdd". Conversion had worked fine.
Created attachment 78513 [details] testfreeze.sdd
Created attachment 78514 [details] testfreeze.odp
Hello Gerry, Thank you for your bug report. I can reproduce that it freezes, First it take 106% of my cpu and 1,5GB of ram after that the CPU use goes back to 1-2% and the ram goes up to 2,4 GB version LibreOffice dev Version: 4.1.0.0.alpha0+ Build ID: 1c0ebe9e0057e6900274f223ff604ee6212e363 spec: macbook pro mid 2012 os: Mac osx 10.8.3 CPU: 2,5 GHZ intel Core i5 ram: 4GB 1600MHZ
I can reproduce the bug with the newest LibreOffice 4.2.3 Version: 4.2.3.3 Build ID: 882f8a0a489bc99a9e60c7905a60226254cb6ff0 (Ubuntu 14.04) I feel free to increase the importance of the bug, because: * it affects all OS (tested Mac, Lin) * It affects the newest LibreOffice version * Freeze 100% reproducable * Unsaved data in other LibreOffice windows lost at freeze.
Priority highest is reserved for MABs, please see: https://wiki.documentfoundation.org/MAB on when a bug qualifies for that. Thus keeping this on priority high.
Tested again with LO 4.3.1.2 and LibreOffice still freezes on opening. It now gives the error message: Fatal Error: bad allocation. System: Windows 7, 64-bit
I have a similar problem. https://bugs.freedesktop.org/show_bug.cgi?id=86714 I have a odt file with lots of tables, when I edit it on writer the cpu consumption rises till to 100% and do not fall so I must kill the process.
Bug still present in LO Version: 4.4.2.2 on Windows 7. LO crashes on loading attached .odp file. Version: 5.0.0.0.alpha1 shows the error message "bad allocation" and crashes afterwards. Can anyone please look into this 100% reproducible crasher bug?
LibreOffice 5.0 rc2 crashes on this .odp file. 100% reproducible. It first shows "bad allocation" and then crashes. Tested on Win7. It would be perfect if someone could have a look at this bug. It is an absolutely obvious crasher bug.
There's a 19 kilometer long dashed line in this presentation, and the time and memory is exhausted generating the polygons for the dashes
The patch at https://gerrit.libreoffice.org/#/c/17036/ would solve this case at least
Created attachment 117227 [details] From sdd to odp converted by AOO3.4.1 The file testfreeze.sdd opens quick in OOo1.1.5. and in AOO3.4.1. I have converted the .sdd file to sxi in OOo1.1.5 and to .odp on AOOO3.4.1. Both converted files open quickly in AOO4.1.1. and in LO5.1. I have attached the .odp file. But the file testfreeze.odp does not open in AOO 4.1.1 but gives the ASCII import dialog. It is likely that the conversion was not correct. Nevertheless LibreOffice should not freeze on such a file.
Hi Caolán, thanks for looking into the bug and providing a fix. Is there anything that I can assist on this bug (e.g. testing)? I think I'll install an old OpenOffice.org 1.1 to see where this 19 km line comes from in this .sdd file :-) If it is of any help I could prepare a new conversion to .odp or provide a screenshot of that original document. Thanks a lot!
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d1046e7c3f66e5f3384ee1ef534ef28346702fc6 Resolves: tdf#63955 clip 19km long line to some sane limit It will be available in 5.1.0. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a5a871bf03b212ce760997b16d764e266207dc55&h=libreoffice-5-0 Resolves: tdf#63955 clip 19km long line to some sane limit It will be available in 5.0.1. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f794f6501bcf18e5430d57128699fc579251f900&h=libreoffice-4-4 Resolves: tdf#63955 clip 19km long line to some sane limit It will be available in 4.4.6. 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.
*** Bug 92763 has been marked as a duplicate of this bug. ***
Oh man, why was this fixed *in the primitive creation* ? Prinitive creation should always represent the 'truth' about the geometry. If decomposition takes too long, the fix should be where it gets decomposed. Each decomposition implementation at the primitive level *has* ViewInformation exactly for that purpose (!) Did I mention that for dashed lines when *clipping* against *something* the dash *will move* and not be the same as when started from the line's start ???
The fix also does not prevent a 18km long line be feeded to rendering from other sources, only one source is elliminated. That's why it should be fixed where it gets visualized/discretisized.