Issue 33366 - .doc save as, OOo freeze
Summary: .doc save as, OOo freeze
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: OOo 1.1.2
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@sw
Depends on:
Reported: 2004-08-24 23:28 UTC by didiera
Modified: 2013-08-07 14:41 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Test MS word document (26.00 KB, application/msword)
2004-08-24 23:31 UTC, didiera
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description didiera 2004-08-24 23:28:16 UTC
When trying to save as sxw this MS Word document (see attachment), OpenOffice
Comment 1 didiera 2004-08-24 23:31:48 UTC
Created attachment 17332 [details]
Test MS word document
Comment 2 michael.ruess 2004-08-25 14:28:15 UTC
MRU->DVO: Saving this in sxw format end up in a loop with heavy memory
consumption and Assertion "Ins 1" from memtools\svarray.cxx. Please have a look
if the import is buggy or it is a Writer format problem. Thanks!
Comment 3 openoffice 2004-10-19 19:40:31 UTC
The problem was caused by a bookmark which extends past the end of a paragraph.
I.e., the bookmark position was (node 17, content 21), but the paragraph only
has 14 characters of text. When this happens,
SwXTextPortionEnumeration::CreatePortions() gets into a loop when it tries to
advance to the next position. E.g., we are at position 12 and want to advance.
The algorithm tries to move to the next position (21) which fails because the
paragraph only has 14 characters. Hence, the current position doesn't change and
we get into a loop.

I fixed this by making sure that in such cases the algorithm advances to
position 14 instead of staying at 12. This probably drops one half of the
bookmark, though. Also, I'm not sure if we should allow such situations in the
core at all, and if not, how to fix this.

dvo->os: Oliver, please do:
1) review my fix at sw/source/core/unocore/unoportenum.cxx, v. 1.27.300.1
2) decide whether we want to allow this situation at all, and if not, should
this be fixed:
  - in the WW8 import
    (where this 'illegal' bookmark is created; from what I remember CMC telling
me, these
     things can happen in the WW8 format)
  - in SwDoc::MakeBookmark
    (which would prevent this irregardless of the source)
  - in unoportenum.cxx
    (don't touch the core, but treat an index > than string length the same as
Also, please reopen/forward the bug as appropriate. :-)
Comment 4 Oliver Specht 2004-10-25 08:40:43 UTC
->dvo: Your fix doesn't hurt but such situations should not be allowed. 
Bookmarks should not point to positions that do not exist. This is not allowed
inside of  the core and the filters should not do this either. 
Please fix it in SwDoc::MakeBookmark()
Comment 5 openoffice 2004-11-03 15:40:13 UTC
Comment 6 openoffice 2004-11-04 16:01:51 UTC
reopen for QA
Comment 7 openoffice 2004-11-04 16:02:40 UTC
dvo->mru: Please test.
Comment 8 michael.ruess 2004-11-05 10:15:04 UTC
Shold have state "fixed".
Comment 9 michael.ruess 2004-11-10 12:38:13 UTC
Verified fix in CWS swqbugfixes09.
Comment 10 michael.ruess 2004-12-27 14:08:55 UTC
Checked integration with 680m67.