Bug 73616 - FILEOPEN: Writer freezes when opening particular .doc file
Summary: FILEOPEN: Writer freezes when opening particular .doc file
Status: RESOLVED DUPLICATE of bug 73936
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: highest major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2014-01-14 16:35 UTC by Mohamed-Ali BEN MANSOUR
Modified: 2014-02-12 16:06 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Document file that can be opened with MS word but not with LibreOffice (168.50 KB, application/msword)
2014-01-14 16:35 UTC, Mohamed-Ali BEN MANSOUR
Details
Backtrace during the freeze (10.57 KB, text/plain)
2014-01-14 19:49 UTC, Arnaud Versini
Details
Loop in document 2 (414.50 KB, application/msword)
2014-01-20 10:34 UTC, Mohamed-Ali BEN MANSOUR
Details
Loop in document 3 (364.00 KB, application/msword)
2014-01-20 10:35 UTC, Mohamed-Ali BEN MANSOUR
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mohamed-Ali BEN MANSOUR 2014-01-14 16:35:27 UTC
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
Comment 1 Joel Madero 2014-01-14 17:28:10 UTC
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
Comment 2 Mohamed-Ali BEN MANSOUR 2014-01-14 17:43:32 UTC
For information, the document can be opened after saving it as .odt file from MS Word.
Comment 3 Mohamed-Ali BEN MANSOUR 2014-01-14 17:47:39 UTC
Testing to open the document after saving it as a .docx file => Fails
Comment 4 Arnaud Versini 2014-01-14 19:49:58 UTC
Created attachment 92085 [details]
Backtrace during the freeze
Comment 5 Michael Meeks 2014-01-14 20:23:55 UTC
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.
Comment 6 Björn Michaelsen 2014-01-17 09:51:50 UTC
(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.
Comment 7 Michael Stahl (CIB) 2014-01-17 20:07:53 UTC
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.
Comment 8 Mohamed-Ali BEN MANSOUR 2014-01-20 10:34:55 UTC
Created attachment 92432 [details]
Loop in document 2
Comment 9 Mohamed-Ali BEN MANSOUR 2014-01-20 10:35:24 UTC
Created attachment 92433 [details]
Loop in document 3
Comment 10 Mohamed-Ali BEN MANSOUR 2014-01-20 10:37:19 UTC
I've added 2 other documents that loop in LO 4.1.4.2
Comment 11 Mohamed-Ali BEN MANSOUR 2014-01-21 13:24:24 UTC
The Files "Loop in document 2" and "Loop in document 3" can be opened with Apache OpenOffice 4.0.1.
Comment 12 Mohamed-Ali BEN MANSOUR 2014-01-22 13:32:43 UTC
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 ?
Comment 13 Mohamed-Ali BEN MANSOUR 2014-02-12 16:06:41 UTC

*** This bug has been marked as a duplicate of bug 73936 ***