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
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 )
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.
Open the file, or at least warn the user that is can't fully open the document
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 135237 [details]
XLSX with pictures hangs libreoffice
Created attachment 135238 [details]
File cleaned with WPS Office by removing all hidden pictures in sheet 1
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 184.108.40.206?
In the second case, could you attach the original xlsx file from your customer?
Created attachment 135265 [details]
Original edited by MSO 2013
(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 220.127.116.11?
> In the second case, could you attach the original xlsx file from your
Here's the original customer file, untouched by Libreoffice nor WPS office.
It was edited by the customer with MSO 2013.
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.
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
Created attachment 135736 [details]
strace on loading original XLSX
strace from master source
Tue Aug 22 13:38:03 2017 +0200
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Setting to: All -> Windows also affected
Version: 18.104.22.168.beta1 (x64)
Build ID: 97471ab4eb4db4c487195658631696bb3238656c
CPU threads: 4; OS: Windows 6.1; UI render: default;
Locale: ru-RU (ru_RU); Calc: CL
Apache OpenOffice 4.1.4
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 22.214.171.124 was not successful
Also gnumeric is with some problems here, but gnumeric makes it.
same in 126.96.36.199 x64 in win10-64
Dear Damien Chambe,
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Reproduced with :
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
NOT reproduced with 3.3 version
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
@@ -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;
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).