Bug 55711

Summary: CRASH FILEOPEN particular .ods with Conditional Formatting
Product: LibreOffice Reporter: Rainer Bielefeld Retired <LibreOffice>
Component: CalcAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal CC: lo_bugs
Priority: medium    
Version: 4.0.0.0.alpha0+ Master   
Hardware: Other   
OS: All   
Whiteboard:
Crash report or crash signature: Regression By:
Bug Depends on:    
Bug Blocks: 44446    
Attachments: typescript of gdb session with backtrace
typescript of session where LO was running

Description Rainer Bielefeld Retired 2012-10-07 05:54:14 UTC
Steps how to with Server-installation of Master "3.7.0.alpha0+  – ENGLISH UI [Build ID: b255de8]" {tinderbox: Win-x86@16, pull time 2012-10-06 09:31:39} on German WIN7 Home Premium (64bit) UserInstallation=$SYSUSERCONFIG/LOdev/3:

0. Download attachment 66051 [details] of "Bug 54400 - Conditional FORMATTING references"
1. Launch LibO
2. open downloaded "sample" from LibO Start Center file menu
   Bug: Crash.

Worked fine with LibO 3.6.0.4, 

Looks similar to "Bug 55379 - FILEOPEN CRASH for particular .ods", might be a DUP, but I have no skills to check that.

@Markus:
Please include this one for your tests concerning Bug 55379
Comment 1 Terrence Enger 2012-10-08 17:31:00 UTC
The attachment linked from the bug description is a .odp attached to
bug 53933 "EDITING: Only one edit for Custom animation (freeform)
path". and I can open it with a recent build from master with no
obvious problem.  The file attached to bug 54400 is a spreadsheet
<https://bugs.freedesktop.org/attachment.cgi?id=66501>, and I am
colledting a backtrace even as I type this.
Comment 2 Terrence Enger 2012-10-08 18:18:25 UTC
Created attachment 68270 [details]
typescript of gdb session with backtrace

While loading the document attached to bug 54400, after displaying an
empty (grey backgound) document window and before painting the
progress bar, LibreOffice became unresponsive.  The system had low CPU
usage.

From another terminal running gdb, I collected output from `thread
apply all backtrace full`, which is the attachment.

LO was so severely hung that it did not respond to ctrl-c in its terminal.


LibroOffice is master commit ccb6535, pulled around 2012-10-07 22:00
UTC, configured with ...

    --enable-symbols
    --enable-dbgutil
    --enable-crashdump
    --disable-build-mozilla
    --without-system-postgresql
    --enable-debug
    --enable-werror

and build and executed on ubuntu-natty (11.04) ...

    $ uname -a
    Linux cougar-natty 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 18:00:43 UTC 2012 i686 athlon i386 GNU/Linux
    $ gcc --version
    gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
    Copyright (C) 2010 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Comment 3 Terrence Enger 2012-10-08 18:19:41 UTC
Created attachment 68271 [details]
typescript of session where LO was running
Comment 4 Michael Meeks 2012-10-08 19:10:12 UTC
Initial link 66051 should be attachment 66501 [details] - the valgrind trace is:


==6114== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 8)
==6095== Invalid write of size 4
==6095==    at 0x117B988E: XMLTableStyleContext::ApplyCondFormat(com::sun::star::uno::Sequence<com::sun::star::table::CellRangeAddress>) (conditio.hxx:353)
==6095==    by 0x117AC404: ScXMLImport::SetStyleToRanges() (xmlimprt.cxx:2683)
==6095==    by 0x117AC7E5: ScXMLImport::SetStyleToRange(ScRange const&, rtl::OUString const*, short, rtl::OUString const*) (xmlimprt.cxx:2738)
==6095==    by 0x1176F101: ScMyStyleRanges::SetStylesToRanges(std::list<ScRange, std::allocator<ScRange> > const&, rtl::OUString const*, short, rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:182)
==6095==    by 0x1176F3C1: ScMyStyleRanges::SetStylesToRanges(rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:198)
==6095==    by 0x1176F7AB: ScMyStylesImportHelper::SetStylesToRanges() (XMLStylesImportHelper.cxx:493)
==6095==    by 0x117BAE1B: ScMyTables::DeleteTable() (xmlsubti.cxx:207)
==6095==    by 0x117BC9A5: ScXMLTableContext::EndElement() (xmltabi.cxx:426)
==6095==    by 0x110DE9F5: SvXMLImport::endElement(rtl::OUString const&) (xmlimp.cxx:716)
==6095==    by 0x113C545C: sax_expatwrap::SaxExpatParser_Impl::callbackEndElement(void*, unsigned short const*) (sax_expat.cxx:817)
...

ie. identical to 55710 although with a different document.

Thanks for the report :-)

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