Download it now!
Bug 55665 - FILESAVE: crash during DOC export of a file containing some specific OLE
Summary: FILESAVE: crash during DOC export of a file containing some specific OLE
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Mike Kaganski
Whiteboard: BSA target:5.0.0
Keywords: filter:doc, filter:rtf
Depends on:
Reported: 2012-10-05 13:35 UTC by Laurent Bonnaud
Modified: 2015-12-17 05:49 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

File to reproduce the bug (2.79 MB, application/vnd.oasis.opendocument.text)
2012-10-05 13:50 UTC, Laurent Bonnaud
Minimal test case for bug 55665 (11.42 KB, application/vnd.oasis.opendocument.text)
2015-05-07 14:21 UTC, Mike Kaganski

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Bonnaud 2012-10-05 13:35:42 UTC
Problem description: 

The attached ODT file cannot be saved as a RTF file.

Steps to reproduce:
1. Load the attached file in LibreOffice
2. Save it as RTF

Current behavior:

LibreOffice displays an error box with this message:
  Error saving the document
  Write Error.
  The file could not be written.

Expected behavior:

LibreOffice manages to save the file.

Platform (if different from the browser): 
Browser: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18.0 Firefox/18.0

This is with Version (Build ID: da8c1e6)

PS: I could not select the correct version in the bug reporting Web interface.
Comment 1 Laurent Bonnaud 2012-10-05 13:50:29 UTC
Created attachment 68118 [details]
File to reproduce the bug
Comment 2 billhook 2012-10-09 05:21:46 UTC
Confirmed on Windows Vista 32 bit on LO

Furthermore, saving the same .odt file as a ".doc (97/XP/2003)" or as a ".doc (Word 95)" crashes LibreOffice completely.

I *could* save the attached .odt as .docx, .html and export as pdf.
Comment 3 billhook 2012-10-09 05:24:28 UTC
@Laurent Did this work in previous versions of OpenOffice?
Comment 4 billhook 2012-10-09 05:32:13 UTC
I wonder if this has anything to do with Bug 51262 - "big rtf file from little odt file"

 * This document is quite big to start with (777 pages; 2,923,499 bytes)
 * It contains a lot of images, and that bug is apparently caused by images in the document.

Just speculation...
Comment 5 Laurent Bonnaud 2012-10-09 17:23:18 UTC
I don't know if previous LO crashed or failed.
Comment 6 Laurent Bonnaud 2012-10-09 17:51:24 UTC
Saving this file to MS Word "DOC" format also crashes on Linux.

I tried with the LibreOffice binary provided in Ubuntu 12.10 and the resulting debugging info can be found there:
Comment 7 Laurent Bonnaud 2012-10-09 18:11:48 UTC
With the binary I downloaded from there is no crash information displayed.  The LO window just disappears.
Comment 8 Mike Kaganski 2012-10-11 22:54:16 UTC
LO under Win7Pro_x64:

Save as RTF -> Error saving the document
Save as DOC (97/XP/2003) -> Crash


Save as DOC (95) -> OK
Comment 9 Mike Kaganski 2012-10-11 23:17:40 UTC
Excuse me, the previous comment is partially incorrect.
If I open the file and immediately try to save as DOC (either 95 or 97+), LO crashes.

But if I open the file, then try to save as RTF, get the error message, then try to save as DOC (either 95 or 97+), then the operation succeedes.
Comment 10 LeMoyne Castle 2012-12-21 23:13:48 UTC
In Version (Build ID: 58f22d5) on Ubuntu 10.04 was able to re-create the RTF file save error but it did not crash when saved as .doc (97-2003).
Comment 11 Paul Unger 2013-05-09 20:23:01 UTC
Running and it crashes every time I try to save a file with tables, pictures, different field types, footnotes, and comments, etc., to .rtf. I don't try to save to .rtf often, so I'm just noticing this behaviour now. Saving to .pdf, .doc, .docx all work fine.
Comment 12 tommy27 2013-09-12 11:12:40 UTC
I think it's "inherited from LibO" I was able to reproduce both RTF and DOC crashes with multiple LibO release up to 3.3.3 (I don't have 3.3.0) and the bug is present in AOO 4.0.0 too.

edited summary. changed version and component fields.
added expert devs to CC list
Comment 13 tommy27 2013-09-12 11:13:10 UTC
P.S. tested under Win7 64bit
Comment 14 Mike Kaganski 2013-09-14 01:10:07 UTC
The test document seems to be broken.

1. If I open the file using any version starting from and up to under Win7x64, it opens with first page empty. When I scroll it down (so that I see some graphics on some pages), and then return to the first page, there are "ghost" graphics in the top left corner of the first page. They may be selected and moved, but if I scroll the document down and up again, they disappear and other graphics appear.

2. The opens the document (with empty first page), and then crashes after a couple of seconds (looks like it continues to process the document after initial display, and the crash happens on some stage of this delayed processing). So, the problem is worse in

Despite the document itself is broken, I think the bug should be fixed, because the crash indicates some flaw in the code that doesn't expect something wrong in the input data. Fixing it will make the software more robust.
Comment 15 Alexandr 2014-07-18 18:27:46 UTC
I reproduce behavior described in comment 9 with LibreOffice 4.2.5 and on Debian x86_64, but the file is saved as rtf with LibreOffice without errors.
Comment 16 Laurent Bonnaud 2014-10-01 16:07:24 UTC
I tested again in Ubuntu 14.10 with LO 1:4.3.2-0ubuntu1:

 - saving as RTF works
 - saving as DOC crashes

I opened a new bug with updated information:
Comment 17 Jean-Baptiste Faure 2014-10-01 20:22:14 UTC
This odt file has been created by conversion from a .doc file. You can verify this point by checking the names of numbering styles, you will find style names like WW8Num1 which are WinWord8 style names.
If you open the Navigator to examine the objects of this document, you will see that there is 10 hidden tables. AFAIK LibreOffice does not have the ability to hide a table. 

I suggest 2 ways to try to fix the problem:
1/ unzip the .odt and remove the hidden tables from the content.xml and compress the file again.
2/ come back to the original .doc file with MS-Word, make sure that all objects included in the document are not hidden, save the file under another name in both formats doc and docx. Convert these new files to .odt using the current stable "Fresh' version of LibreOffice.

Best regards. JBF
Comment 18 Laurent Bonnaud 2014-10-02 08:36:41 UTC
Thank you for the analysis of this crash!  I will update the bug title...

Thanks again for the workaround!  However LO needs a fix anyway.
Comment 19 Jean-Baptiste Faure 2014-10-02 09:55:15 UTC
(In reply to Laurent Bonnaud from comment #18)
> Thank you for the analysis of this crash!  I will update the bug title...
> Thanks again for the workaround!  However LO needs a fix anyway.

It worked ? which one ? ;-)

Best regards. JBF
Comment 20 Laurent Bonnaud 2014-10-02 10:48:03 UTC
> It worked ? which one ? ;-)

I did not even try because I do not care about this document (it is not even mine).
Comment 21 Mike Kaganski 2015-05-07 14:21:09 UTC
Created attachment 115415 [details]
Minimal test case for bug 55665

(In reply to Jean-Baptiste Faure from comment #17)
> If you open the Navigator to examine the objects of this document, you will
> see that there is 10 hidden tables. AFAIK LibreOffice does not have the
> ability to hide a table.
These hidden tables are parts of custom page styles that are defined in the document, but not used. LO can easily create these. To get rid of the tables, simply remove all custom page styles, or aply each style and remove tables from its header/footer, or just remove headers/footers altogether.

Actually, the problem is not the tables. There is a bug processing one of OLE objects in the file, namely Object 65. It is a formula on page 525 ((1) of C. SIGMOID descriptor). Removing it, the problem disappears. Besides, scrolling so that it gets displayed on screen removes the crash, too.

Here is the minimal test file that is enough to show the problem. It contains the following required items:
1. Some paragraphs to move OLE objects to second page (manual page break doesn't do the trick)
2. The problematic OLE itself
3. Another OLE just next to problematic one

Submitted patch to gerrit -
Comment 22 Commit Notification 2015-05-07 15:53:57 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

tdf#55665: Fix a corner case OLE processing

It will be available in 5.0.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 23 Robinson Tryon (qubit) 2015-12-17 05:49:26 UTC
Migrating Whiteboard tags to Keywords: (filter:doc, filter:rtf)