Bug 111461 - XLSX with 0px height or 0px width images hangs LO and produce a lot of temp files
Summary: XLSX with 0px height or 0px width images hangs LO and produce a lot of temp f...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.4.6.3 release
Hardware: x86-64 (AMD64) All
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: XLSX
  Show dependency treegraph
 
Reported: 2017-08-07 19:28 UTC by Damien Chambe
Modified: 2019-09-16 20:46 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
XLSX with pictures hangs libreoffice (205.57 KB, application/wps-office.xlsx)
2017-08-07 19:30 UTC, Damien Chambe
Details
File cleaned with WPS Office by removing all hidden pictures in sheet 1 (12.59 KB, application/wps-office.xlsx)
2017-08-07 19:31 UTC, Damien Chambe
Details
Original edited by MSO 2013 (244.09 KB, application/wps-office.xlsx)
2017-08-08 09:21 UTC, Damien Chambe
Details
strace on loading original XLSX (481.21 KB, application/x-bzip)
2017-08-22 15:59 UTC, Damien Chambe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Damien Chambe 2017-08-07 19:28:11 UTC
Description:
This hang.XLSX produced by MS Office (unknown version as it has been sent by a customer by mail) hangs LibreOffice.
In /tmp, a folder is created lu188442iogk4.tmp with a lot of file such as lu188442ioglh.tmp . At least 6 gb are produced. (after that my disk was full )

Opening with WPS Office, I have detected a hundred of images inserted in the first sheet, near cell O4, with either a 0px height or a 0px width. If I delete those images, the file is correctly opened by LibreOffice, see the other file clean.xlsx


Version: 5.4.0.3
Build ID: 1:5.4.0~rc3-0ubuntu0.16.04.1~lo1
Threads CPU : 4; OS : Linux 4.10; UI Render : par défaut; VCL : gtk3; 
Locale : fr-FR (fr_FR.UTF-8); Calc: CL

And reproduced on another ubuntu installation with Libroffice 5.3.5 on linux/ubuntu

Steps to Reproduce:
1. Open hang.XLSX
2. Watch for a folder created in tmp folder, a lot of tmp files are created ( > 6gb for a 210 kb worksheet file )
3.

Actual Results:  
LibreOffice hangs and will probability fill your disk with tmp files. This could prevent the OS to boot normally. Some tmp files are pictures, other are unknown binary content.

Expected Results:
Open the file, or at least warn the user that is can't fully open the document


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Damien Chambe 2017-08-07 19:30:20 UTC
Created attachment 135237 [details]
XLSX with pictures hangs libreoffice
Comment 2 Damien Chambe 2017-08-07 19:31:03 UTC
Created attachment 135238 [details]
File cleaned with WPS Office by removing all hidden pictures in sheet 1
Comment 3 Julien Nabet 2017-08-08 06:57:01 UTC
Just to be clear, the second attachment is xlsx cleaned with WPSOffice but about the first attachment, is it the original xslx file from MsOffice or is it the result of saving in LO 5.3.5.2?
In the second case, could you attach the original xlsx file from your customer?
Comment 4 Damien Chambe 2017-08-08 09:21:15 UTC
Created attachment 135265 [details]
Original edited by MSO 2013
Comment 5 Damien Chambe 2017-08-08 09:25:15 UTC
(In reply to Julien Nabet from comment #3)
> Just to be clear, the second attachment is xlsx cleaned with WPSOffice but
> about the first attachment, is it the original xslx file from MsOffice or is
> it the result of saving in LO 5.3.5.2?
> In the second case, could you attach the original xlsx file from your
> customer?

Here's the original customer file, untouched by Libreoffice nor WPS office.
It was edited by the customer with MSO 2013.
Comment 6 Julien Nabet 2017-08-08 09:29:13 UTC
Thank you for your feedback.
I'll take some time to confirm it after my day time job.
But certainly someone may give it a try before.
Comment 7 Julien Nabet 2017-08-12 06:01:08 UTC
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.

I noticed this repeated trace on console:
warn:oox:5947:1:oox/source/drawingml/shapecontext.cxx:126: ShapeContext::onCreateContext: unhandled element: 3971
Comment 8 Damien Chambe 2017-08-22 15:59:49 UTC
Created attachment 135736 [details]
strace on loading original XLSX

strace from master source 
cc2cb0123ac599bf25c5e17b97b5d7bf93d3e487 
Tue Aug 22 13:38:03 2017 +0200
Comment 9 Telesto 2017-08-22 18:31:35 UTC
Repro with:
Versie: 4.4.6.3 
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: nl_NL

Setting to: All -> Windows also affected
Comment 10 XTR 2017-12-06 14:08:22 UTC
Repro with:
Version: 6.0.0.0.beta1 (x64)
Build ID: 97471ab4eb4db4c487195658631696bb3238656c
CPU threads: 4; OS: Windows 6.1; UI render: default; 
Locale: ru-RU (ru_RU); Calc: CL

and with
Apache OpenOffice 4.1.4
Comment 11 paulystefan 2018-06-21 23:09:44 UTC
i made a test with gnumeric 1.12.17 in windows

it reads the mso-file fast.

the new saved gnumeric xml-file is about 189 MB. wow!!!

save as a ods 1.2 extended creates a file with 182 MB.

about factor 800 in relation to source.

A test with actual gnumeric on linux can show more.

reading of this gnumeric export in LOO 5.4.7 and in LOO 6.0.5.1 was not successful

Also gnumeric is with some problems here, but gnumeric makes it.
Comment 12 paulystefan 2018-08-25 14:11:56 UTC
same in 6.1.0.3 x64 in win10-64
Comment 13 QA Administrators 2019-09-02 09:25:43 UTC Comment hidden (obsolete)
Comment 14 Damien Chambe 2019-09-02 20:28:25 UTC
Reproduced with :
Version: 6.3.1.2
Build ID: 1:6.3.1~rc2-0ubuntu0.18.04.1~lo1
Threads CPU : 4; OS : Linux 5.0; UI Render : par défaut; VCL: gtk3; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: CL
Comment 15 Damien Chambe 2019-09-02 20:36:25 UTC
NOT reproduced with 3.3 version
Comment 16 Julien Nabet 2019-09-16 20:38:06 UTC
On pc Debian x86-64 with master sources updated today, I noticed these logs:
warn:legacy.osl:3832:3832:oox/source/helper/graphichelper.cxx:120: GraphicHelper::GraphicHelper - cannot get target frame
warn:oox:3832:3832:oox/source/drawingml/shapecontext.cxx:130: ShapeContext::onCreateContext: unhandled element: 3973
warn:vcl.gdi:3832:3832:vcl/source/graphic/Manager.cxx:141: Calculated size mismatch. Variable size is '28365646' but calculated size is '19039954'

(for the third one, I used:
diff --git a/vcl/source/graphic/Manager.cxx b/vcl/source/graphic/Manager.cxx
index ec2bdca9be0b..941fb45bd9b8 100644
--- a/vcl/source/graphic/Manager.cxx
+++ b/vcl/source/graphic/Manager.cxx
@@ -138,7 +138,7 @@ void Manager::registerGraphic(const std::shared_ptr<ImpGraphic>& pImpGraphic,
 
     if (calculatedSize != mnUsedSize)
     {
-        SAL_INFO_IF(calculatedSize != mnUsedSize, "vcl.gdi",
+        SAL_WARN_IF(calculatedSize != mnUsedSize, "vcl.gdi",
                     "Calculated size mismatch. Variable size is '"
                         << mnUsedSize << "' but calculated size is '" << calculatedSize << "'");
         mnUsedSize = calculatedSize;
)
Comment 17 Julien Nabet 2019-09-16 20:46:19 UTC
Tomaz: following error quoted in my previous comment, I took a look to git history of the file and thought you might be interested in this one.
(of course, I may be wrong, so don't hesitate to uncc yourself in this case).