Created attachment 99325 [details] File is Edit protected. Problem description: After doing the initial phase of analysis, we can say that the crash is due to the <w:documentProtection> tag. LO is not able to export this tag and gets hanged while saving. If we remove this tag from settings.xml from the original document, then there is not issue observed. Steps to reproduce: 1. Open file in LibreOffice 2. Click File -> Save As (Microsoft word 2007/2010(.docx)) 3. It saves as .docx 4. Open the same file again which got roundtripped. Current behaviour: Lo gets hanged while saving the file. Expected behaviour: LO should be able to save the file properly. Operating System: All Version: 4.3.0.0.alpha1
After the furhter Analysis, it was observed that the issue is not due to the "documentProtection" tag preservation. Will keep update the issue shortly
Updating version - at least a problem since 4.2.4.2 - complete crash there. Version is the oldest version that we can confirm the problem, not the latest (we use comments for that). Going to continue analyzing now.
Actually - can you simplify this document to the bare bones that causes the issue? These complex documents are very difficult for developers to handle. Please delete pages and see how minimal you can get it to create the bug. It very well could be the same issue causing bug 78904
I have tried simplyfing the document in several ways. But no luck. The problem is, even if i delete any single letter from the document, then document gets Round Tripped properly and after round trip it is opening in MS office also. It would be great if you could suggest any direction for such kind of issue. Thanks.
well that's crazy ;) thanks for that additional information. Assuming you didn't want to assign yourself to this - removing your name from the developer assignee
Thank you for reporting this issue! I have been able to confirm the issue on: Version: 4.3.0.0.alpha0 Date: Thu Apr 24 21:43:16 2014 +0300 Platform :Ubuntu 14.04 DE: GNOME3 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm this problem I am marking as: New (confirmed) Major - crash/data loss High Keywords - Whiteboard Status - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage also - we'd love to see you in the chat! - http://webchat.freenode.net/?channels=libreoffice-qa There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
39dd70e5e97abbf62e0a60bdd4e64e1f03bb4057 is the first bad commit commit 39dd70e5e97abbf62e0a60bdd4e64e1f03bb4057 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Oct 17 09:03:15 2013 +0000 source-hash-c4cca49f49408bc4094bdfcf782de2f7cd16ce6a commit c4cca49f49408bc4094bdfcf782de2f7cd16ce6a Author: Luboš Luňák <l.lunak@suse.cz> AuthorDate: Fri May 31 18:58:38 2013 +0200 Commit: Luboš Luňák <l.lunak@suse.cz> CommitDate: Fri May 31 20:00:54 2013 +0200 obey --enable-werror when building clang plugin Change-Id: I8ca9b09a6ffd4b2f00740563fa9682fdabb26b3d :100644 100644 bbf58ac4174cf089533cc9eaaf2404bab894403d 27848ba16c148657f41ac7b1df02e091a44dd29f M ccache.log :100644 100644 d3fd19007fc85bc8ea470ccfc86bd490af47f1e6 601e47632607a385493e43c480061748c2ca4c7b M commitmsg :100644 100644 ac438b7c167103f3948b708a3a33f72474002040 21e4be7670edb7af70f3d7bf4f3a21a45c2e09bd M dev-install.log :100644 100644 081ac2e5df01c821467b09853438cba7a301aefe fc4c2507cb79b70a4e64b27a328ce2b4507374f9 M make.log :040000 040000 59487f80225ae3f18f67d1fee7742edd8021cdc8 787f0b310a532028f6ef2a3b46651a6000091148 M opt # bad: [793dbf6f80f497dfe587d560d6257f42a24273f6] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [8092559c5013969ebda017d79200463b9b975038] source-hash-fd84daf696a368c2c7561b5253b32a63ecdeca4a git bisect good 8092559c5013969ebda017d79200463b9b975038 # bad: [0270ef1b76a6de423b30f7927362cc01c1a0fc38] source-hash-b1f7dd66b898b03cb4bd8d434b6370310ea95946 git bisect bad 0270ef1b76a6de423b30f7927362cc01c1a0fc38 # good: [aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1] source-hash-358b60b3b172968a7605b428af01df456d7669b2 git bisect good aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1 # good: [63ac4ab9665db60fac1e1813c9c80da52b2e87c6] source-hash-66e39940d763586060c4bcc8c3cd213495c40b79 git bisect good 63ac4ab9665db60fac1e1813c9c80da52b2e87c6 # bad: [318bcb373da01174e1947da5e3ce77e078a33a77] source-hash-4a143c44fe7ad266ab9ab7dca317b0099b1438d0 git bisect bad 318bcb373da01174e1947da5e3ce77e078a33a77 # bad: [e7831b72c3ba577f9b95d9e45f8a8e0aa3f02be3] source-hash-bb6ecd8b40313b7cc83d4e619029f4e001334a52 git bisect bad e7831b72c3ba577f9b95d9e45f8a8e0aa3f02be3 # good: [796cc4f8eec3565f31fbd2adc95588a325312df2] source-hash-b45876bf0f2eeafba0a4f9f8f30cd4279eb2aa3e git bisect good 796cc4f8eec3565f31fbd2adc95588a325312df2 # bad: [39dd70e5e97abbf62e0a60bdd4e64e1f03bb4057] source-hash-c4cca49f49408bc4094bdfcf782de2f7cd16ce6a git bisect bad 39dd70e5e97abbf62e0a60bdd4e64e1f03bb4057 # good: [06085544fbc6f810000d39f786528e5dbe8171c6] source-hash-1de66ba440855050a794b3b2a8647c1b02c210b8 git bisect good 06085544fbc6f810000d39f786528e5dbe8171c6 # first bad commit: [39dd70e5e97abbf62e0a60bdd4e64e1f03bb4057] source-hash-c4cca49f49408bc4094bdfcf782de2f7cd16ce6a
- On Furhter Analisys, It was understood that if we try to saveAs this fiel in MS office 2010, then there is no issue. - The original file is prepared in MS office 2007. - So we need to optimise in MS office 2007 only. - After optimizing this file in 2007, still the exact are a of main issue could not be higlighted. - No proper pattern is identified.
By Mistake It was marked as Resolved FIxed. So re-opening the same.
This is the latest observation: - The file is basically Edit protected. Edited settings.xml, have removed <w:documentProtection> tag, to be able to edit the document. - When we open this document in LO, we scroll down and when we reach these pages. the number of pages starts increasing. - Below are the observations after optimizing the file. - The file contains pages where there is Wrapped text. One line text overlapped with an image. There are two such pages. - If we remove these two pages the document works fine. - The special part about these pages is that there is a wrapping style applied to these two problematic pages. - The Wrapping style applied is "Through" and the Wrap text property is "Both Side" - LO is not able to handle this Wrapping style. - As mentioned before, the number of pages increases as LO is not able to determine the exact position of these two images. - I created a sample document wherein I overlapped a text with a image and applied the same Wrapping properties. - This sample document when opened in LO, it was not imported completely. The image was totally missing. Only text was loaded.
The attached file now saves without hanging in 4.4.0.2 and 4.5 master (but not 4.3.5.2) However, given that it seems to have been the below commit which made it work, which relates to import rather than export, I wonder whether the problem has just been papered over. Adding Cc: to vmiklos@collabora.co.uk; Could you shed any light on this one? Before the below commit, saving the attached file gets stuck in an infinite loop. Is there any chance this is a real fix, or has it just prevented reproduction of a still existing problem using the original file? commit 29cbbad64088354425c606f9eb6c267bdf7731dc Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Fri Nov 7 10:13:08 2014 +0100 DOCX import: fix rounding error in table cell widths Change-Id: I733fd4b998ba4d0bde2f91f2b3d76205f0dc8020
I'm afraid this is still a problem. Opening the bugdoc with today's master results in layout adding infinite number of pages to the document, while the same doesn't happen with the .doc equivalent of it, so there is something to fix here.
(In reply to Miklos Vajna from comment #12) I confirm this. I can open this file just fine in LO 4.2.8 but LO 4.4.5 is constantly loading new pages. Hopefully devs will be able to locate the problem by comparing how old version does it.
Pages 39 and 40 of the bugdoc have strange pictures: while nominally the text would have to be wrapped around them, they have extreme large (negative) top margin, and it seems Word performs no wrapping, but they are simply in front of the text (covering it). I'll take care of this.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=37b5f1ed3139b8569bfec0fcb5077f6b66b79acd tdf#78902 VML import: workaround for extreme top margin It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d66df3d35030bf725fa7e3d78420344ddd44478c&h=libreoffice-5-0 tdf#78902 VML import: workaround for extreme top margin It will be available in 5.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]