Bug 59918 - FILESAVE: FILEOPEN: save document as docx and reopen result in an freeze/endless loop
Summary: FILESAVE: FILEOPEN: save document as docx and reopen result in an freeze/endl...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
3.6.4.3 release
Hardware: x86-64 (AMD64) All
: highest major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: DOCX-Opening
  Show dependency treegraph
 
Reported: 2013-01-27 00:22 UTC by Jorendc
Modified: 2017-02-16 16:02 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Fino cap 7 per Alessandro - saved with Word 2013 as docx (868.22 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-10-29 12:11 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorendc 2013-01-27 00:22:35 UTC
Tested with Linux Mint 14 x64 Libreoffice 4.0.0.2 rc2 and latest master (pulled today) Version 4.1.0.0.alpha0+ (Build ID: f1bca26afcc7593d0124c216c0400a9e2e47fc1).

Download attachment of Bug 58086. Download link: https://bugs.freedesktop.org/attachment.cgi?id=71267

Steps:
* Open with LibreOffice
* Save file as .docx
* Close LibreOffice
* Reopen LibreOffice
* reopen .docx you just created

Current behavior: freeze

Expected: no freeze :-).

While running the 4.1 master version I saw following endless repeated output in my terminal: 

warn:writerfilter:13543:1:/home/joren/core/writerfilter/source/dmapper/DomainMapper.cxx:1450: DomainMapper::attribute() - Id: 92502 / 0x16956 value: 0 / 0x0
warn:writerfilter:13543:1:/home/joren/core/writerfilter/source/dmapper/DomainMapper.cxx:1450: DomainMapper::attribute() - Id: 92501 / 0x16955 value: 92146 / 0x167f2
warn:writerfilter:13543:1:/home/joren/core/writerfilter/source/dmapper/DomainMapper.cxx:1450: DomainMapper::attribute() - Id: 92502 / 0x16956 value: 1 / 0x1
warn:writerfilter:13543:1:/home/joren/core/writerfilter/source/dmapper/DomainMapper.cxx:1450: DomainMapper::attribute() - Id: 92502 / 0x16956 value: 2 / 0x2
warn:writerfilter:13543:1:/home/joren/core/writerfilter/source/dmapper/DomainMapper.cxx:1450: DomainMapper::attribute() - Id: 92502 / 0x16956 value: 3 / 0x3
warn:writerfilter:13543:1:/home/joren/core/writerfilter/source/dmapper/DomainMapper.cxx:1450: DomainMapper::attribute() - Id: 92502 / 0x16956 value: 4 / 0x4
warn:writerfilter:13543:1:/home/joren/core/writerfilter/source/dmapper/DomainMapper.cxx:1450: DomainMapper::attribute() - Id: 92502 / 0x16956 value: 4 / 0x4
warn:writerfilter:13543:1:/home/joren/core/writerfilter/source/dmapper/DomainMapper.cxx:1450: DomainMapper::attribute() - Id: 92501 / 0x16955 value: 92145 / 0x167f1
Comment 1 Jorendc 2013-01-27 00:24:55 UTC
Following https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg I mark my own bug as Major High
Comment 2 Joel Madero 2013-01-27 22:05:50 UTC
Confirmed on 3.6.4.3, agree with priority :)
Comment 3 Jean-Baptiste Faure 2013-01-27 22:07:26 UTC
Reproducible under Ubuntu 12.04 x86-64 with Version 4.0.1.0+ (Build ID: c4820200312e3d50a12d3605147772759938bcf)
and Version 4.0.0.2 .0.2 (Build ID: 408fe71bd18616c467b3dcd7ab6756528ffcae2)
Not sure if LO is frozen or if it take very very long time to open the file.

Best regards. JBF
Comment 4 Timur 2013-05-03 13:47:15 UTC
Reproducible on Windows 7 x64 with Lo 354 and 403 (RC), so instead of Platform: Linux I put Platform: All.
Comment 5 Jean-Baptiste Faure 2013-05-04 06:54:23 UTC
I tried again with LO 4.1.0.0.alpha0+ Build ID: a80ae494533f3be2009d623478ff57e16bcc8be under Ubuntu 12.04 x86-64.
It took a very long time to open the docx file and gnome-shell crashed.

I put Miklos and Cédric in CC in case they are not informed of this problem.

Best regards. JBF
Comment 6 Timur 2013-10-09 16:38:31 UTC
Using LO 4.1.2 on Windows to save document as docx, I cannot reopen it in MS Office 2013, it says:
"A document must contain exactly one root element. 
Location: Part: /word/document.xml, Line; 2, Column: 21600297"
Comment 7 sophie 2013-11-05 13:12:59 UTC
still confirmed with version Version: 4.1.3.2
Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a - Sophie
Comment 8 Björn Michaelsen 2014-01-17 09:51:52 UTC Comment hidden (obsolete)
Comment 9 tommy27 2014-05-02 15:01:45 UTC
.docx save freeze still reproducible using LibO 4.2.3.3
moving to the mab4.2 list since 4.1.x is END OF LIFE

P.S. saving as .doc is possible but is very slow (almost 15 minutes)
Comment 10 Jan Holesovsky 2014-05-15 09:14:17 UTC
Unfortunately this document is impossible to handle by a developer with its current size; can you please try to minimize it to a testcase?

Please take the original document, cut it in the half (delete the rest) & try the procedure you described - does the problem still happen?  If yes, then cut the half in half again; and continue until you have a document where it does not happen.

Then take the smallest one where the problem was still happening, and cut it from the beginning - now delete the 1st half, then half of the remaining half etc. until you get a small document where the problem is still visible.

Then please attach this minimized document that still shows the problem here :-)

Thank you a lot!
Comment 11 Timur 2014-05-19 14:59:31 UTC
Using LO 4.2.4 on Windows to save document as docx, I can reopen it in MS Office 2010 normally and in LO but VERY slowly. 
(In reply to comment #6)
> Using LO 4.1.2 on Windows to save document as docx, I cannot reopen it in MS
> Office 2013, it says:
> "A document must contain exactly one root element. 
> Location: Part: /word/document.xml, Line; 2, Column: 21600297"

Using LO 4.2.4 on Windows to save the document as docx, I can reopen it in MS Office 2010 normally but in LO VERY slowly - which is still an improvement from the freeze.
Comment 12 Jean-Baptiste Faure 2014-07-20 11:15:31 UTC
Tested again, this time with version 4.3.1.0.0+ under Ubuntu 14.04 x86-64.
The docx takes very long time to open but finally it opens and the document is editable. 
What is surprising me is that the docx has 29 bookmarks that are not in the original odt file. Additionally I found a graphic object (an hidden line) on the first page of the docx that is not listed by the Navigator. I didn't find this object in the original odt.

I think the original issue reported here has been solved somewhere, the performance issue being another thing.

Best regards. JBF
Comment 13 tommy27 2014-10-05 18:31:54 UTC
tested under Win7x64

if I try loading the test document in 4.3.2.2 or recent 4.4.0.0 daily build I get this error message:

The file 'Fino cap 7 per Alessandro.odt' is corrupt and therefore cannot be opened. LibreOfficeDev can try to repair the file.

The corruption could be the result of document manipulation or of structural document damage due to data transmission.

We recommend that you do not trust the content of the repaired document.
Execution of macros is disabled for this document.

Should LibreOfficeDev repair the file?

If I click YES a blank document is loaded.
Comment 14 Timur 2014-10-29 11:50:57 UTC
(In reply to tommy27 from comment #13)
> tested under Win7x64
> if I try loading the test document in 4.3.2.2 or recent 4.4.0.0 daily build
> I get this error message:
> The file 'Fino cap 7 per Alessandro.odt' is corrupt and therefore cannot be
> opened. LibreOfficeDev can try to repair the file.

You say you can't open the original ODT at all? I open it normally in LO on Win7x64 (237 pages), although slowly, I can't open it in MS Word 2010, and I can open in MS Word 2013 (239 pages).

(In reply to Timur from comment #11)
> Using LO 4.2.4 on Windows to save the document as docx, I can reopen it in
> MS Office 2010 normally but in LO VERY slowly - which is still an
> improvement from the freeze.

Using LO 4.4.0 master from today on Windows, I can open ODT, but when I save the document as DOCX, I can reopen it in MS Office 2010 normally (245 pages) but in LO VERY slowly. 

(In reply to Jean-Baptiste Faure from comment #12)
> I think the original issue reported here has been solved somewhere, the
> performance issue being another thing.

Maybe. Should this be closed then, or reported as another bug, or left open until explained?
Comment 15 Timur 2014-10-29 12:11:52 UTC
Created attachment 108619 [details]
Fino cap 7 per Alessandro - saved with Word 2013 as docx

This docx still opens very slowly with LO, while it opens normally with MS Word.

I just noticed the original ODT has 159 converted sections, and wrong formatting starts from page 10. 

Correction: I was able to open original ODT also with Word 2010, but after the warning, which 2013 doesn't show (maybe due to odt version).
Comment 16 tommy27 2014-11-19 04:21:25 UTC
I can load the original .ODT version of the file but after savig as .docx and reloading I still experience freeze with LibO 4.4.0.0 alpha2+ 

LibO 4.2.x reached the end of life
moving this from mab4.2 to mab4.3 list.
Comment 17 Xisco Faulí 2015-09-16 13:54:46 UTC
This issue is still present in

Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: es-ES (es_ES)

on Windows 7 (64-bit)
Comment 18 Robinson Tryon (qubit) 2015-12-09 18:07:59 UTC Comment hidden (obsolete)
Comment 19 Andrey Skvortsov 2016-06-23 10:38:17 UTC
The issue doesn't exist in LO 5.1.3 (Win amd64) and LO 5.1.4 (Linux amd64). In both cases new saved document is loaded, but it took time. 
I'd set status to resolved.
Comment 20 Andrey Skvortsov 2016-06-23 10:43:56 UTC
The issue doesn't exist in LO 5.1.3 (Win amd64) and LO 5.1.4 (Linux amd64). In both cases new saved document is loaded. Loading is slow, but successful.
Comment 21 Buovjaga 2016-12-13 09:28:01 UTC
Closing this, opened bug 104627 for the opening time issue.
Comment 22 tommy27 2016-12-13 09:43:25 UTC
it still freezes LibO 5.2.3.3 and 5.4.0.0 alpha in my Win7 x64 using an SSD disk and an Intel Core i7 CPU @3.07 GHz, 8 GB RAM

so I revert status to NEW
Comment 23 Buovjaga 2016-12-13 09:52:24 UTC
(In reply to tommy27 from comment #22)
> it still freezes LibO 5.2.3.3 and 5.4.0.0 alpha in my Win7 x64 using an SSD
> disk and an Intel Core i7 CPU @3.07 GHz, 8 GB RAM
> 
> so I revert status to NEW

And how long did you wait?
Comment 24 Andrey Skvortsov 2016-12-13 10:20:14 UTC
LO 5.2.3.1 (amd64, GNU/Linux) the document is loaded successfully.
Comment 25 tommy27 2016-12-13 10:42:04 UTC
retested. it loads after 10 minutes. 
WORSKFORME 
sorry 4 the noise