Bug 47347 - FILEOPEN: Crashes when opening rtf file with 3.5.0 - correct with 3.4.5
Summary: FILEOPEN: Crashes when opening rtf file with 3.5.0 - correct with 3.4.5
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: BSA target:3.6.0 target:3.5.4
Keywords: filter:rtf, regression
Depends on:
Blocks:
 
Reported: 2012-03-15 04:17 UTC by lcostaouec
Modified: 2015-12-17 12:04 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Original file (which crashes with LibO 3.5.0) and the same (save as by MSO 2010) that then works with LibO 3.5.0) (10.61 KB, application/zip)
2012-03-15 04:17 UTC, lcostaouec
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lcostaouec 2012-03-15 04:17:34 UTC
Created attachment 58496 [details]
Original file (which crashes with LibO 3.5.0) and the same (save as by MSO 2010) that then works with LibO 3.5.0)

Problem description: LibO 3.5 does not succeed in opening RTF "hand-made" file (see attachment - toto.rtf file). It works with LibO 3.4.5. Once file is opened by MSOffice 2010 and save as a new file (without any modifications - see attachment toto-word.rtf file), this one could be then opened by LibO 3.5.0 (and 3.4.5)

Steps to reproduce:
1. Open toto.rtf file with LibO 3.5.0

Current behavior: Crash

Expected behavior: Open file

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Comment 1 s-joyemusequna 2012-03-15 08:29:19 UTC
Confirmed with LibO 3.5.1 RC2 (=final) on Windows XP.

Original file: 
  LibO 3.5.1 RC2 : LibO crashes while loading the file
  Word 2007, OOo 3.1, LibO 3.3.4, LibO 3.4.5 : no problems

File resaved with Word:
  LibO 3.5.1 RC2 (and Word 2007) : works fine.
  OOo 3.1 and LibO 3.3.4 : nearly OK (=usable) 
  LibO 3.4.5 : display is garbled (greeks characters etc.)

This is a regression.
Comment 2 Korrawit Pruegsanusak 2012-03-17 02:40:51 UTC
Miklos, could you please have a look? Thanks :)
Comment 3 Jean-Baptiste Faure 2012-03-23 14:30:19 UTC
With LO 3.5.3rc0+ running in a terminal, I get the following error message:
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

So I guess it has the same root cause than bug 47353.

Miklos: it is one for you. Please feel free to reassign if you can't handle this bug.

Best regards. JBF
Comment 4 Caolán McNamara 2012-05-05 06:01:54 UTC
a) crash appears to be fixed in master, anyone still able to reproduce it there ?
b) encoding problem remains, but the hand-crafted toto.rtf has \fonttbl{\fo this should surely be \fonttbl{\f0 i.e. a 0 not an o ?, if I change that it works correctly.
Comment 5 Not Assigned 2012-05-05 08:00:01 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=349d64b821c657aa9b94667c7f9fac3bdb677342

Related: fdo#47347 m_aFontEncodings is a map so returns 0 on unknown fontindex
Comment 6 Not Assigned 2012-05-05 08:00:34 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a96e7428b74504cf9ca9e02b21a5647a3aa55e56

Resolves: fdo#47347 overwrite incorrect font table entry with the correct one
Comment 7 Caolán McNamara 2012-05-05 08:02:19 UTC
caolanm->vmiklos: double-check those commits and cherry-pick them to 3-5 if you feel its necessary. Fairly edge-case stuff though, mightn't be worth it. invalid properties from fo take up the std::map slot so when the good properties come around there's something in the map already and the new ones don't replace the old ones, so the fontname sticks as "Symbol"
Comment 8 Jean-Baptiste Faure 2012-05-05 08:03:14 UTC
Hi Caolan,

(In reply to comment #4)
> a) crash appears to be fixed in master, anyone still able to reproduce it there
> ?

No crash anymore for me with master (Version ID : c1ac12f) and LibreOffice
3.5.3.2 (Version ID : 235ab8a-3802056-4a8fed3-2d66ea8-e241b80) under Ubuntu
11.10 x86_64.
Do you know which commit solved the problem ? bug 47353 seems to be fixed too.

> b) encoding problem remains, but the hand-crafted toto.rtf has \fonttbl{\fo
> this should surely be \fonttbl{\f0 i.e. a 0 not an o ?, if I change that it
> works correctly.

indeed. :-)

Best regards. JBF
Comment 9 lcostaouec 2012-05-07 03:24:03 UTC
There is no more crash on Windows 7 with LibO 3.5.3.2 but if you compare the 2 original attached files, there is still something wrong with HTML tags since array is not correct.
Thanks by advance to consider again status.
Best regards,
L.Costaouec
Comment 10 s-joyemusequna 2012-05-07 04:15:04 UTC
No crash but ..
.. file toto.rtf: table is not displayed correctly with LibO 3.5.3 - same problem with version 3.6.0alpha0+ (Build ID: 34513fe). File is two pages instead of one.
Dark cell background in tables is missing etc.

(Note: with 3.5.3 I replaced the defective \fo tag  with \f0; 3.6 alpha works as expected here)

No problems with LibO 3.4.5 (and Word 2007). Tested under Windows XP and Vista 64.
Comment 11 Jean-Baptiste Faure 2012-05-07 13:39:41 UTC
(In reply to comment #9)
> There is no more crash on Windows 7 with LibO 3.5.3.2 but if you compare the 2
> original attached files, there is still something wrong with HTML tags since
> array is not correct.
> Thanks by advance to consider again status.

Your original bug report was only about a crash. This crash is now fixed. 
For clarity, I suggest to close this bug report as fixed and open another one for the formatting problems.

Best regards. JBF
Comment 12 Caolán McNamara 2012-05-08 00:32:59 UTC
Yeah, this was reported originally as "file crashes", and that's fixed, so lets leave this bug as "fixed" and open a new one if necessary for a specific import fidelity flaw.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=567c1db25bd705faac44203e4a3d01d0f5e1385c is possibly a fix a for a goodly number of table-related bugs
Comment 13 lcostaouec 2012-05-08 13:05:50 UTC
Hi,
You are right : I will do as suggested,
Best regards,
L.Costaouec
Comment 14 Not Assigned 2012-05-09 01:33:21 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4112bb446659d7b60b17202e3f1e40ad1ea3d6a6&g=libreoffice-3-5

Resolves: fdo#47347 overwrite incorrect font table entry with the correct one


It will be available in LibreOffice 3.5.4.
Comment 15 s-joyemusequna 2012-05-19 02:19:32 UTC
Verified with LOdev 3.6 (master - 18-May-2012 02h44 x86@6-fast; Build ID: 8b1d29b) under Windows Vista 64. No crash.
Comment 16 Robinson Tryon (qubit) 2015-12-17 12:04:52 UTC Comment hidden (obsolete)