Created attachment 92052 [details] Document file that can be opened with MS word but not with LibreOffice Problem description: FILEOPEN Writer hangs indefinitely when opening attached .doc Operating System: All Version: 4.1.4.2 release
Confirmed on Ubuntu 13.10 with LibreOffice 4.2 bisect below: 7e20e241c1d8819d8d5edb7894baeddde33f9d3a is the first bad commit commit 7e20e241c1d8819d8d5edb7894baeddde33f9d3a Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon Dec 10 16:56:37 2012 +0000 source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f commit 2c270eeff422ef93100376ce0717a131d4f3cc2f Author: Noel Grandin <noel@peralex.com> AuthorDate: Thu Sep 27 11:13:36 2012 +0200 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Tue Oct 2 14:57:21 2012 +0200 sal_Bool->bool in svl::SvtCTLOptions Change-Id: I824595b6b60d4114f27bf64d8a84f2973f778e39 :100644 100644 bb0656bf0e9f0e5434df794c30f03cbda13f2a50 38dc03e977851c756e61106b6db493b10de02c99 M ccache.log :100644 100644 3c804da7834c2b648a6e8b4b4e5bc70991c8750d c19b829e87fb53084b31a7860e45893cf000cfe1 M commitmsg :100644 100644 6e14a7ced0a4273629b6f0f3e8d394c2f13e5a85 51e43cc9f26ae5acc4be3ff43a0a7d38ef9c4b60 M dev-install.log :100644 100644 5df31cb652d9cefe1fb4e23c67b42fc7c3a0abc4 f95ac418b220b519b7dcc1dac6a82af9d2831893 M make.log :040000 040000 02973d13b56dc9b01b6505828b2243ceb3fe3aec 900097acda714632f1d909f18fdde993ec63c01d M opt # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # bad: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect bad 114fd3b76bcba890e6d702d00cef910f1493c262 # good: [6af64581913aa7ce3fcf0890fe671830d416a6ea] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f git bisect good 6af64581913aa7ce3fcf0890fe671830d416a6ea # bad: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f git bisect bad 7e20e241c1d8819d8d5edb7894baeddde33f9d3a # good: [18ab426f67674e3ca169118f1f7a3527613374a4] source-hash-4df639baacd871cb2793e75dd9721ad2ae715e20 git bisect good 18ab426f67674e3ca169118f1f7a3527613374a4 # good: [5ee3b045c8fc3f18ec00e41fdb3966073d2192df] source-hash-ee34432562393a4549e9e77f71146e43c5d02233 git bisect good 5ee3b045c8fc3f18ec00e41fdb3966073d2192df # good: [ee1cb4f1eac09d356398a8c954ce1fea93407265] source-hash-968ed85d7304fe0044d3f82af20ae7190ad3c33d git bisect good ee1cb4f1eac09d356398a8c954ce1fea93407265 # first bad commit: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f
For information, the document can be opened after saving it as .odt file from MS Word.
Testing to open the document after saving it as a .docx file => Fails
Created attachment 92085 [details] Backtrace during the freeze
Looks like a reasonably normal layout loop. I guess we should have a tracker bug for known layout loops, there were no shortage of them in the past, certainly; "loop free layout" has drastically reduced their number I guess.
(This is an automated message.) Setting priority to highest as this is a 4.1 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
loop introduced by: commit b966a09c2da9441961c93c44be556399575db849 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Mon Oct 1 23:57:06 2012 +0100 Resolves: fdo#54862 extra ++n causing merged cells to be skipped commit 567c1db25bd705faac44203e4a3d01d0f5e1385c reverted a pile of other commits, including 858b5b4f36a357fe7192e7c2ed9cc3cdfc81fd8f but didn't revert the ++n of that commit, leading to merge groups getting skipped the document loops in 4.0.0.3 already and in 3.5.7.2 too and also in OOo 3.3 and 3.2.1 too. ...reading bug 54862 is becomes clear what happened: the WW8 filter had for some time (starting in 3.6.0) a bug in the import of merged table cells, and that bug was fixed by the above commit. so this bug is not really a regression, it was pure accident that this document does not loop when the tables are not properly imported.
Created attachment 92432 [details] Loop in document 2
Created attachment 92433 [details] Loop in document 3
I've added 2 other documents that loop in LO 4.1.4.2
The Files "Loop in document 2" and "Loop in document 3" can be opened with Apache OpenOffice 4.0.1.
Micheal, A Rollback on the commit that resolves [fdo#54862 extra ++n causing merged cells to be skipped], can actually open the first doc file but not the 2 others (Loop in document 2/3). The problem seems to be other than merged table cells in that case. Do you confirm ?
*** This bug has been marked as a duplicate of bug 73936 ***