Bug 51112 - Created RTF-crashes
Summary: Created RTF-crashes
Status: RESOLVED DUPLICATE of bug 49178
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: x86-64 (AMD64) Windows (All)
: medium critical
Assignee: Miklos Vajna
URL:
Whiteboard: target:3.7.0
Keywords: filter:rtf, regression
Depends on:
Blocks:
 
Reported: 2012-06-15 04:11 UTC by tapio.andersson
Modified: 2015-12-17 12:06 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Original RTF-template file (120.02 KB, application/msword)
2012-06-15 04:11 UTC, tapio.andersson
Details
Saved file that causes crashes (313.85 KB, application/rtf)
2012-06-15 04:12 UTC, tapio.andersson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tapio.andersson 2012-06-15 04:11:33 UTC
Created attachment 63067 [details]
Original RTF-template file

There are some bug in Open Office 3.5.4.2. Saving this original_file.rtf again in RTF-format causes crash when it's opened again with Libre Office.

When I open this attached original_file.rtf everything seems to be ok. When I save this file again in RTF-format with different filename file seems to be saved ok.

When I open created new file then some serious bug happens. Libre Office crashes.

There might be some encoding issue. This original_file contains letters ö and ä (a with dots and o with dots).

Regards,
Tapio Andersson
Comment 1 tapio.andersson 2012-06-15 04:12:32 UTC
Created attachment 63068 [details]
Saved file that causes crashes
Comment 2 tapio.andersson 2012-06-15 04:15:44 UTC
Reason why I think that this issue might be some bug in encoding is that when I open saved file with Windows Wordpad I see some kanji marks in places where should be marks ä or ö.
Comment 3 s-joyemusequna 2012-06-15 08:49:10 UTC
Confirmed. Works fine with LibO 3.4.5 => regression.

Doesn't work with LibO 3.5.4 and LOdev 3.7 (master - 2012-06-14, Win-x86@6-fast; Build ID: 5af60dc). No crashes for me. Tested with Windows XP and Vista 64.

Possible encoding problem with 3.5.4 (chinese signs); this seems to work in LOdev 3.7.

Both 3.5.4 and 3.7 have a problem with tables. This can be a duplicate of one of the rtf table bugs.
Comment 4 Jean-Baptiste Faure 2012-06-16 14:59:44 UTC
No crash for me with LibreOffice 3.5.6rc0+ Version ID : c61881d-a73d29c-33cdb70-f269e46-d162a5a under Ubuntu 11.10 x86_64
No crash with LibreOffice 3.5.4.2 Version ID : 165a79a-7059095-e13bb37-fef39a4-9503d18
I tried to save again the original RTF file with LO 3.5.4.2 : no crash nor encoding problem with the resulting RTF file.

Best regards. JBF
Comment 5 Michael Meeks 2012-07-06 05:00:55 UTC
No crash here either, but running under valgrind I see some things of interest (though this is a slightly old build) Miklos ?

==2648== Invalid read of size 4
==2648==    at 0x12941410: writerfilter::dmapper::DomainMapperTableManager::endOfRowAction() (DomainMapperTableManager.cxx:492)
==2648==    by 0x129466BC: writerfilter::TableManager<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>, boost::shared_ptr<writerfilter::dmapper::TablePropertyMap> >::endParagraphGroup() (TableManager.hxx:791)
==2648==    by 0x1291E568: writerfilter::dmapper::DomainMapper::lcl_endParagraphGroup() (DomainMapper.cxx:3247)
==2648==    by 0x11FBDE24: writerfilter::LoggedStream::endParagraphGroup() (LoggedResources.cxx:132)
==2648==    by 0x12AD3B36: writerfilter::rtftok::RTFDocumentImpl::tableBreak() (rtfdocumentimpl.cxx:481)
==2648==    by 0x12AD9AEF: writerfilter::rtftok::RTFDocumentImpl::dispatchSymbol(writerfilter::rtftok::RTFKeyword) (rtfdocumentimpl.cxx:1582)
==2648==    by 0x12AF3ECE: writerfilter::rtftok::RTFTokenizer::dispatchKeyword(rtl::OString&, bool, int) (rtftokenizer.cxx:299)
==2648==    by 0x12AF416F: writerfilter::rtftok::RTFTokenizer::resolveKeyword() (rtftokenizer.cxx:260)
==2648==    by 0x12AF4460: writerfilter::rtftok::RTFTokenizer::resolveParse() (rtftokenizer.cxx:123)
==2648==    by 0x12AD35EF: writerfilter::rtftok::RTFDocumentImpl::resolve(writerfilter::Stream&) (rtfdocumentimpl.cxx:596)
==2648==    by 0x11FAC00B: RtfFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (RtfFilter.cxx:100)
==2648==    by 0x47AD572: SfxObjectShell::ImportFrom(SfxMedium&, bool) (objstor.cxx:2240)
==2648==  Address 0xe4bc7b4 is 4 bytes before a block of size 16 alloc'd
==2648==    at 0x4028C39: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2648==    by 0x12943C4E: std::vector<long, std::allocator<long> >::push_back(long&&) (vector.tcc:102)
==2648==    by 0x129420DF: writerfilter::dmapper::DomainMapperTableManager::sprm(writerfilter::Sprm&) (DomainMapperTableManager.cxx:230)
==2648==    by 0x129289AD: writerfilter::dmapper::DomainMapper::lcl_sprm(writerfilter::Sprm&) (DomainMapper.cxx:1444)
==2648==    by 0x11FBDF77: writerfilter::LoggedProperties::sprm(writerfilter::Sprm&) (LoggedResources.cxx:311)
==2648==    by 0x12AF47C7: writerfilter::rtftok::RTFReferenceProperties::resolve(writerfilter::Properties&) (rtfreferenceproperties.cxx:56)
==2648==    by 0x1291E4A1: writerfilter::dmapper::DomainMapper::lcl_props(boost::shared_ptr<writerfilter::Reference<writerfilter::Properties> >) (DomainMapper.cxx:3456)
==2648==    by 0x11FBE0D7: writerfilter::LoggedStream::props(boost::shared_ptr<writerfilter::Reference<writerfilter::Properties> >) (LoggedResources.cxx:224)
==2648==    by 0x12AD9ADE: writerfilter::rtftok::RTFDocumentImpl::dispatchSymbol(writerfilter::rtftok::RTFKeyword) (rtfdocumentimpl.cxx:1580)
==2648==    by 0x12AF3ECE: writerfilter::rtftok::RTFTokenizer::dispatchKeyword(rtl::OString&, bool, int) (rtftokenizer.cxx:299)
==2648==    by 0x12AF416F: writerfilter::rtftok::RTFTokenizer::resolveKeyword() (rtftokenizer.cxx:260)
==2648==    by 0x12AF4460: writerfilter::rtftok::RTFTokenizer::resolveParse() (rtftokenizer.cxx:123)

I guess that might turn into a crash-on-load under windows :-)
Comment 6 Urmas 2012-07-06 22:03:03 UTC
The table after "Muut kuursit" heading looks corrupted...
Comment 7 Julien Nabet 2012-07-08 13:50:25 UTC
On pc Debian x86-64, with master sources updated today, I didn't reproduce any crash.

I had anyway a lot of console messages and the files were quite long to open
Comment 8 Miklos Vajna 2012-08-09 16:43:46 UTC
No crash here, either - but I see RTF_CLSHDNG is ignored on import. I'll fix that in a bit, and check with valgrind later.
Comment 9 Not Assigned 2012-08-09 16:47:39 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

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

Related: fdo#51112 import RTF_CLSHDNG
Comment 10 Miklos Vajna 2012-08-10 10:21:31 UTC
OK, I can reproduce the crash with 3.5.4 on Windows 7.
Comment 11 Miklos Vajna 2012-08-10 10:57:51 UTC
And it's fixed in 3.5.5, so I think this will be http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b989477dc3d4b1c3296f65e18028090669cf9f2

Thanks for the report, anyway!

*** This bug has been marked as a duplicate of bug 49178 ***
Comment 12 Robinson Tryon (qubit) 2015-12-17 12:06:58 UTC
Migrating Whiteboard tags to Keywords: (filter:rtf)
Replace rtf_filter -> filter:rtf.
[NinjaEdit]