Bug 63955 - CRASH on FILEOPEN .odp presentation. "Bad allocation" -> Crash. 100% reproducible.
Summary: CRASH on FILEOPEN .odp presentation. "Bad allocation" -> Crash. 100% reproduc...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: high critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.1.0 target:5.0.1 target:4.4.6
Keywords:
: 92763 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-04-26 10:09 UTC by Gerry
Modified: 2023-01-27 03:24 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
testfreeze.sdd (38.00 KB, application/vnd.stardivision.impress)
2013-04-26 10:10 UTC, Gerry
Details
testfreeze.odp (129.25 KB, application/vnd.oasis.opendocument.presentation)
2013-04-26 10:10 UTC, Gerry
Details
From sdd to odp converted by AOO3.4.1 (20.08 KB, application/vnd.oasis.opendocument.presentation)
2015-07-14 12:26 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerry 2013-04-26 10:09:24 UTC
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.
Comment 1 Gerry 2013-04-26 10:10:04 UTC
Created attachment 78513 [details]
testfreeze.sdd
Comment 2 Gerry 2013-04-26 10:10:24 UTC
Created attachment 78514 [details]
testfreeze.odp
Comment 3 Thomas van der Meulen [retired] 2013-04-26 14:50:16 UTC
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
Comment 4 Gerry 2014-04-11 18:09:13 UTC
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.
Comment 5 Björn Michaelsen 2014-07-12 20:18:12 UTC
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.
Comment 6 Gerry 2014-09-26 12:20:11 UTC
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
Comment 7 caralu1974 2014-12-18 20:57:22 UTC
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.
Comment 8 Gerry 2015-04-24 21:17:03 UTC
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?
Comment 9 Gerry 2015-07-10 07:31:57 UTC
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.
Comment 10 Caolán McNamara 2015-07-14 09:20:02 UTC
There's a 19 kilometer long dashed line in this presentation, and the time and memory is exhausted generating the polygons for the dashes
Comment 11 Caolán McNamara 2015-07-14 11:39:41 UTC
The patch at https://gerrit.libreoffice.org/#/c/17036/ would solve this case at least
Comment 12 Regina Henschel 2015-07-14 12:26:16 UTC
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.
Comment 13 Gerry 2015-07-14 12:30:51 UTC
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!
Comment 14 Commit Notification 2015-07-15 12:12:00 UTC
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.
Comment 15 Commit Notification 2015-07-15 19:32:20 UTC
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.
Comment 16 Commit Notification 2015-07-16 09:10:43 UTC
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.
Comment 17 Michael Stahl (allotropia) 2015-08-21 15:20:37 UTC
*** Bug 92763 has been marked as a duplicate of this bug. ***
Comment 18 Armin Le Grand 2018-02-22 17:33:56 UTC
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 ???
Comment 19 Armin Le Grand 2018-02-22 17:36:49 UTC
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.