Created attachment 111867 [details]
file that hangs libreoffice when opened
The attached file causes LibreOffice Writer to hang when it is opened. The CPU is stuck at 100% and memory use keeps increasing.
The problem is reproducible.
The file is a greeked version of the original. The file was greeked by unzipping and running the attached xslt over the contents of the xml files. This replaced all [a-zA-Z0-9] with 'a'. This changed file also hangs LibreOffice.
Created attachment 111868 [details]
xslt used for greeking the original file
Build ID: 430m0(Build:2)
Comment on attachment 111867 [details]
file that hangs libreoffice when opened
TESTING with Ubuntu 14.04 (x86-64) +
LO Version: 22.214.171.124.alpha0+
Build ID: 5c60dab390d66a4d5abeaf548efecf3913b90839
(In reply to Jos van den Oever from comment #0)
> Created attachment 111867 [details]
> file that hangs libreoffice when opened
> The attached file causes LibreOffice Writer to hang when it is opened. The
> CPU is stuck at 100% and memory use keeps increasing.
CONFIRMED -- 100% CPU and memory creeping upwards
I only let it go for about 45 seconds.
Status -> NEW
It's possible that this is a performance issue, but I'm not sure. I'll test on a beefier machine (this machine is a Core2duo T8300 @2.4GHz + 4G RAM)
(In reply to Robinson Tryon (qubit) from comment #4)
> [test with] attachment 111867 [details]
> > file that hangs libreoffice when opened
> > The attached file causes LibreOffice Writer to hang when it is opened. The
> > CPU is stuck at 100% and memory use keeps increasing.
> It's possible that this is a performance issue, but I'm not sure. I'll test
> on a beefier machine (this machine is a Core2duo T8300 @2.4GHz + 4G RAM)
Hangs on a Mac Mini as well (quad-core i7 + 16G RAM).
Platform -> All
Whiteboard -> perf
This is still a problem in LibreOffice 126.96.36.199.
Opening bug.docx hangs one cpu core at 100% for at least a minute.
Migrating Whiteboard tags to Keywords: (perf)
Created attachment 134734 [details]
debug WinDBG from procdump
When someone submits a bug, always need to be asked how document was created. Hpw was original created (MSO or LO) and how attached docx was created.
If this DOCX was saved or changed by LO then it's another FILESAVE bug, that can be fixed only if reproducible with steps.
Othwerwise, this FILEOPEN bug is useless and can be closed as INVALID.
This DOCX cannot be open with MSO, says the file is corrupt.
What's not clear is how Open XML Productivity Tools finds no validation errors.
So I set back to Needinfo.
I do not the original file anymore. The file was created with MS Office. It was greeked to hide confidential information.
I guess we may change this bug from ability to open file to message that file is corrupt and cannot be open, maybe repaired. Hang is not acceptable.
** Please read this message in its entirety before responding **
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!
Created attachment 148955 [details]
Word 2016 repaired bugdoc
No longer hangs in 7.0 since:
László Németh <firstname.lastname@example.org> Tue Jan 28 14:32:54 2020 +0100
László Németh <email@example.com> Wed Jan 29 11:00:34 2020 +0100
tdf#128959 DOCX import: fix missing text lines in tables
*** This bug has been marked as a duplicate of bug 128959 ***
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":
tdf#88126: sw_ooxmlexport15: Add unittest
It will be available in 7.1.0.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
This issue is happening again since
author László Németh <firstname.lastname@example.org> 2021-02-10 00:12:52 +0100
committer László Németh <email@example.com> 2021-02-12 18:27:31 +0100
commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 (patch)
parent 3380163bc0fb9dab7f289cc36b0eeb0c9b3ddaa9 (diff)
tdf#76260 DOCX import: fix slow footnote import
it was only working by accident...
(In reply to Xisco Faulí from comment #17)
I see you committed a unit test for this, was it removed by someone? If the unit test worked then this should not be broken again.
(In reply to Kevin Suo from comment #18)
> (In reply to Xisco Faulí from comment #17)
> I see you committed a unit test for this, was it removed by someone? If the
> unit test worked then this should not be broken again.
See the commit message in
Then maybe we can find the commit which caused the "accident". No matter what, we should never hang or crash. If the file is corrupted, then tell the user and try to repair; if repair fails, then exit.