Bug 55617 - FILEOPEN: Conditional formatting: crash when opening a particular file created with master and modified with LO 3.5
Summary: FILEOPEN: Conditional formatting: crash when opening a particular file create...
Status: RESOLVED DUPLICATE of bug 55710
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2012-10-04 11:07 UTC by Jean-Baptiste Faure
Modified: 2013-11-16 15:58 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
bugdoc with CF created with master (52.88 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-10-04 11:07 UTC, Jean-Baptiste Faure
Details
bugdoc with CF modified by LO 3.5 (52.80 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-10-04 11:08 UTC, Jean-Baptiste Faure
Details
backtrace for LO 3.7.0.0.alpha+ (ID 232969d) (19.15 KB, text/plain)
2012-10-04 11:11 UTC, Jean-Baptiste Faure
Details
valgring logs (17.10 KB, application/x-bzip2)
2012-10-04 19:45 UTC, Jean-Baptiste Faure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Baptiste Faure 2012-10-04 11:07:00 UTC
Created attachment 68074 [details]
bugdoc with CF created with master

Here is the description of a crash with current master (ID: 232969d). The crash is linked to Conditional Formatting (CF).
Steps to reproduce:
1/ open attached file with LO 3.5; it is a simplified version of https://bugs.freedesktop.org/attachment.cgi?id=66910
   a) not CF on the second sheet
   b) all CF on the first sheet have been defined using the master
   c) no range with CF are overlapping on another one 
2/ do some change on the data, do not change CF, save under another name and close the file
3/ open the new file with master
==> crash on loading the file
I will attach the file created with the master, the file saved with LO 3.5.7.1 and the backtrace from my gdb session.

Notes:
1/ I do not reproduce the crash with https://bugs.freedesktop.org/attachment.cgi?id=67218 (file with CF from bug 54940 by Markus)
2/ In my bugdoc some CF are defined by 2 conditions. ATM I do not know if that plays some role in the crash.
3/ my first guess was overlapping ranges, so I created CF with not overlapping ranges in CF, and the crash still occurs.

Hope this help. Of course I can do more tests if needed. Please ask me.
Best regards. JBF
Comment 1 Jean-Baptiste Faure 2012-10-04 11:08:11 UTC
Created attachment 68075 [details]
bugdoc with CF modified by LO 3.5
Comment 2 Jean-Baptiste Faure 2012-10-04 11:11:58 UTC
Created attachment 68076 [details]
backtrace for LO 3.7.0.0.alpha+ (ID 232969d)
Comment 3 Michael Meeks 2012-10-04 11:24:22 UTC
I reproduce loading that file.
Comment 4 Michael Meeks 2012-10-04 11:36:27 UTC
Valgrind shows:

==19937== Invalid write of size 4
==19937==    at 0x117B3720: XMLTableStyleContext::ApplyCondFormat(com::sun::star::uno::Sequence<com::sun::star::table::CellRangeAddress>) (conditio.hxx:353)
==19937==    by 0x117A61A8: ScXMLImport::SetStyleToRanges() (xmlimprt.cxx:2683)
==19937==    by 0x117A6589: ScXMLImport::SetStyleToRange(ScRange const&, rtl::OUString const*, short, rtl::OUString const*) (xmlimprt.cxx:2738)
==19937==    by 0x11768DB5: ScMyStyleRanges::SetStylesToRanges(std::list<ScRange, std::allocator<ScRange> > const&, rtl::OUString const*, short, rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:182)
==19937==    by 0x11769022: ScMyStyleRanges::SetStylesToRanges(rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:191)
==19937==    by 0x1176945F: ScMyStylesImportHelper::SetStylesToRanges() (XMLStylesImportHelper.cxx:493)
==19937==    by 0x117B4DD7: ScMyTables::DeleteTable() (xmlsubti.cxx:207)
==19937==    by 0x117B6961: ScXMLTableContext::EndElement() (xmltabi.cxx:426)
==19937==    by 0x110D99F5: SvXMLImport::endElement(rtl::OUString const&) (xmlimp.cxx:716)
==19937==    by 0x113C045C: sax_expatwrap::SaxExpatParser_Impl::callbackEndElement(void*, unsigned short const*) (sax_expat.cxx:817)
==19937==    by 0x113CB1CC: doContent (xmlparse.c:2532)
==19937==    by 0x113CB73B: contentProcessor (xmlparse.c:2105)
==19937==    by 0x113CCE03: XML_ParseBuffer (xmlparse.c:1651)
==19937==    by 0x113C0C1F: sax_expatwrap::SaxExpatParser_Impl::parse() (sax_expat.cxx:743)
==19937==    by 0x113C17CC: sax_expatwrap::SaxExpatParser::parseStream(com::sun::star::xml::sax::InputSource const&) (sax_expat.cxx:531)
...
==19937==  Address 0x143c4034 is 4 bytes inside a block of size 44 free'd
==19937==    at 0x4027F33: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==19937==    by 0x116808C2: ScTable::AddCondFormat(ScConditionalFormat*) (reversible_ptr_container.hpp:57)
==19937==    by 0x115F4194: ScDocument::AddCondFormat(ScConditionalFormat*, short) (documen4.cxx:599)
==19937==    by 0x117B3712: XMLTableStyleContext::ApplyCondFormat(com::sun::star::uno::Sequence<com::sun::star::table::CellRangeAddress>) (xmlstyli.cxx:470)
==19937==    by 0x117A61A8: ScXMLImport::SetStyleToRanges() (xmlimprt.cxx:2683)
==19937==    by 0x117A6589: ScXMLImport::SetStyleToRange(ScRange const&, rtl::OUString const*, short, rtl::OUString const*) (xmlimprt.cxx:2738)
==19937==    by 0x11768DB5: ScMyStyleRanges::SetStylesToRanges(std::list<ScRange, std::allocator<ScRange> > const&, rtl::OUString const*, short, rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:182)
==19937==    by 0x11769022: ScMyStyleRanges::SetStylesToRanges(rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:191)
==19937==    by 0x1176945F: ScMyStylesImportHelper::SetStylesToRanges() (XMLStylesImportHelper.cxx:493)
==19937==    by 0x117B4DD7: ScMyTables::DeleteTable() (xmlsubti.cxx:207)
==19937==    by 0x117B6961: ScXMLTableContext::EndElement() (xmltabi.cxx:426)
==19937==    by 0x110D99F5: SvXMLImport::endElement(rtl::OUString const&) (xmlimp.cxx:716)
==19937==    by 0x113C045C: sax_expatwrap::SaxExpatParser_Impl::callbackEndElement(void*, unsigned short const*) (sax_expat.cxx:817)
==19937==    by 0x113CB1CC: doContent (xmlparse.c:2532)
==19937==    by 0x113CB73B: contentProcessor (xmlparse.c:2105)
==19937==    by 0x113CCE03: XML_ParseBuffer (xmlparse.c:1651)
==19937==    by 0x113C0C1F: sax_expatwrap::SaxExpatParser_Impl::parse() (sax_expat.cxx:743)
==19937==    by 0x113C17CC: sax_expatwrap::SaxExpatParser::parseStream(com::sun::star::xml::sax::InputSource const&) (sax_expat.cxx:531)
Comment 5 Jean-Baptiste Faure 2012-10-04 19:45:20 UTC
Created attachment 68091 [details]
valgring logs

Here is an archive with 2 valgring logs: one, with test1 in its name, has been done in interactive mode. The second, with test2 in its name, has been done with the bugdoc filename on the soffice command line.

Hope this helps.

Best regards. JBF
Comment 6 Markus Mohrhard 2012-10-09 05:09:33 UTC

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