Created attachment 83363 [details] Not open file DOC Problem description: Steps to reproduce: 1. Not open file 2. Libreoffice not responding Current behavior: Expected behavior: Operating System: Windows 7 Version: 4.1.0.4 release
Seems like this is another rendition of the image caching problem - The file will open but you need a lot of RAM and it chews it up (I have 4 gigs and this file just went through it) Marking as New Critical High Updated version to match tracker bug - this was inherited from OOo I believe
test files freezes either LibO 4.1.0.4 or 3.3.4. changing version to 3.3.4 (but probably even older releases are affected).
NoRepro:4.2.2.1:OSX While this is a rather insane file with lots of images and weired formatting, LO manages to open it without a hang. Should the file still not open for you in LO 4.2.2.1 please re-open.
Not open file LO 4.2.3.1 Windows 7 x64
No this very silly 68 page document of images and cyrillic word art text does not open on Version: 4.2.2.1 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f nor on Version: 4.3.0.0.alpha0+ Build ID: aeab0183e86fe011d32058864c02b2de4da32dc9 TinderBox: Win-x86@39, Branch:master, Time: 2014-03-24_05:49:26 On same system with MS Office 2007, it does open in Word's 'compatibility mode' but there is considerable shift of the text word art and images as if the page framing is out of sync. Probably remains a legitimate corner case example for bug 47148
(In reply to comment #5) > No this very silly 68 page document of images and cyrillic word art text > does not open on > > Version: 4.2.2.1 > Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f > > nor on > > Version: 4.3.0.0.alpha0+ > Build ID: aeab0183e86fe011d32058864c02b2de4da32dc9 > TinderBox: Win-x86@39, Branch:master, Time: 2014-03-24_05:49:26 not opens is 4.2.3.3 as well. I wonder if trying to delete some pages of those 68 in MS Word may help to identify which one causes the bug in order to have a minima test case. unfortunately I have no MS Word licence to test
can't still open it in 4.3.2.2 as well (Win7x64)
Created attachment 117435 [details] backtrace Heavens to Betsy! A backtrace, even. Windows Vista 64 Version: 5.1.0.0.alpha1+ Build ID: 8cfdd81b70ef37927b40497ffd10034f28335034 TinderBox: Win-x86@39, Branch:master, Time: 2015-07-24_02:47:18
Created attachment 122373 [details] Not open file saved as DOCX also doesn't open
After waiting for some time, the files do open with Version: 5.2.3.3 (x64) Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU Threads: 2; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US); Calc: single Scrolling / editing is 'a bit slow', but that's another problem I guess.
With Linux 16.04 it did open for me after a minute, but used 2.7GB of RAM and kept one CPU maxed at 100% even after the document was loaded.
can open doc file, but it use 4.5 gig off ram and 25% cpu load Version: 6.2.0.0.alpha0+ Build ID: 3c01b8cc4f15df16b4373855b8797d5dcff59327 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group threaded
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed these logs: warn:legacy.osl:30696:30696:oox/source/helper/graphichelper.cxx:120: GraphicHelper::GraphicHelper - cannot get target frame warn:legacy.osl:30696:30696:sw/source/filter/ww8/writerhelper.cxx:586: No NodeIndex in SwFrameFormat ?, suspicious
with LO 6.4.1.2 x64 win 10 x64 test docx works, but the file has some failures. saving Docx again in excel 2016 the file is more actual in docx-format. new opening in LO 6.4.1.2 x64 win 10 x64 the file is again opening and the pictures and text in good shapes in relation to excel 2016.
Created attachment 158561 [details] load in 6.4.1.2 of docx in odt LO 6.4.1.2 x64 win 10 x64 save docx file in odt
Created attachment 158562 [details] docx new save in excel 2016 MS Excel 2016 loads the file with message old format. so i save in excel 2016 format.
Created attachment 158563 [details] docx new save in excel 2016 and saved in LO6412 in odt docx new save in excel 2016 and saved in LO6412 in odt better quality of import. problem of loading also solved. better handling of Microsoft Office files. Actual save with actual MS Office solve many problems in Libre Office for Import.
Created attachment 158564 [details] doc saved in LO6412 in odt doc load and saved in LO6412 in odt load problem solved quality of pictures and fonts like excel 2016.
Version: 6.4.2.1 x64 used 4 GB of RAM
paulystefan@web.de: I cannot understand what you did with saving in MSO and as ODT, but that's not the point of this bug. This is simple Fileopen bug where LO hardly opens original DOC or DOCX (saved in MSO from DOC without change), for a long time and a lot of RAM (I closed at 2,5 GB and counting). MSO 2016 opens 68 pages with 140 MB. Repro 7.0+. I set New again.
Created attachment 158625 [details] Flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
LO 6.4.1.2 i load original files in about 45 sec doc RAM needed 4.3 GB docx RAM needed 3.5 GB but no load crash like first message so you are right, there is a ram problem.
Created attachment 158681 [details] reduced to first page odt of doc LO 6.4.1.2 x64 win 10-64 odt of doc is also with the problem inside. full odt downloaded before in 158561 needs about 4000 MB Ram or more. first page here needs big 291 MB Ram. full document is with 68 pages. so the problem is now reduced for more analysis in detail.
Created attachment 158682 [details] doc reduced to first page in MSO2016 compatibility mode reduced to first page of original doc in mso 2016. also 291 MB RAM in LO 6.4.1.2 x64 in win-10 so the problem is reduced for more analysis in detail
Created attachment 158683 [details] export gif of first page from doc in mso 2016 gif animation is running in LO 6.4.1.2 in doc and odt
Created attachment 158684 [details] import gif of first page of doc in new odt LO 6.4.1.2 needs more than 220 MB Ram gif-animation runs only marked the animation is static frozen
see bug 104874 big gif animation is slow in impress perhaps same problem
correction see bug 104878 big gif animation is slow in impress perhaps same problem
in mso word a gif with animation ist not permanent running. it only shows the first picture.
A horrible bug doc.. I would guess an anchoring problem. mixed with drawing polygons
my workarounds: 1.save as DOCX in MSO 2016 or higher 2. option change to no animation in LO But there are only 67 pages in LO 7132 with much difference to DOCX and DOC. Perhaps there are some improvements in LO 7.2.0 with the better importer.
See no signifikant improvement in LO 7202 Version: 7.2.0.2 (x64) / LibreOffice Community Build ID: 614be4f5c67816389257027dc5e56c801a547089 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL A partial workaround: new saving in MSO201x.
Does open.. however with some delay - 25 seconds or so Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d5e55d204b71710eb5eb5d2c683dd6698626df3c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Without animation option Does open in Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL
I gave a new try with master sources updated today on initial doc, it's quite quick to open, idem with LO Debian package 7.4.1 Could someone give a try with 7.4.1 or a daily master build?
Ilmari: would you have some time to give it a try?
(In reply to Julien Nabet from comment #36) > Ilmari: would you have some time to give it a try? Testing with attachment 83363 [details], stopwatch time to responsive is about 25 secs for me, still takes some processing to be *fully* responsive after that. So seems to be the same results as in 2021. Not sure what the goal would be, but let's lower the severity. Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 922b79a0f5a9151a6870ba395abcac5b54055275 CPU threads: 2; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded Jumbo
Created attachment 182503 [details] Flamegraph On pc Debian x86-64 with master sources updated today + gen rendering, I retrieved a Flamegraph during opening of https://bugs.documentfoundation.org/attachment.cgi?id=83363, if it can help.
(In reply to Buovjaga from comment #37) > Testing with attachment 83363 [details], stopwatch time to responsive is > about 25 secs for me, still takes some processing to be *fully* responsive > after that. So seems to be the same results as in 2021. Not sure what the > goal would be, but let's lower the severity. > > Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: 922b79a0f5a9151a6870ba395abcac5b54055275 > CPU threads: 2; OS: Windows 10.0 Build 19044; UI render: default; VCL: win > Locale: fi-FI (fi_FI); UI: en-US > Calc: threaded Jumbo Still the same in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0ee9501c0b7dc1a291715fff9c1934b1c08cb654 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: threaded