Bug Hunting Session
Bug 55710 - CRASH FILEOPEN particular .ods with Conditional Formatting
Summary: CRASH FILEOPEN particular .ods with Conditional Formatting
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.2.1 rc
Hardware: Other All
: medium major
Assignee: Markus Mohrhard
URL:
Whiteboard: target:3.7.0 target:3.6.3
Keywords:
: 55617 55711 55760 55780 55879 (view as bug list)
Depends on:
Blocks: mab3.6 54400
  Show dependency treegraph
 
Reported: 2012-10-07 05:06 UTC by Rainer Bielefeld Retired
Modified: 2012-10-15 19:08 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Response in terminal (11.17 KB, text/plain)
2012-10-07 19:14 UTC, Zirneklītis
Details
gdb session, inculding thread apply all backtrace full (113.15 KB, text/plain)
2012-10-08 19:16 UTC, Terrence Enger
Details
copy of terminal output where LO was running (1.60 KB, text/plain)
2012-10-08 19:17 UTC, Terrence Enger
Details
valgrind output (613.41 KB, text/plain)
2012-10-08 19:56 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2012-10-07 05:06:11 UTC
Steps how to reproduce with Server Installation of "LibreOffice 3.6.2.1 release”  English UI/ German Locale [Build-ID:  da8c1e6] on German WIN7 Home Premium (64bit):

0. Download attachment 68045 [details] of "Bug 55584 - Conditional formatting is 
  damaged by deleting a column"
1. Launch LibO
2. open downloaded "CondForm.ods"
   Bug: Crash.

Worked fine with LibO 3.6.0.4, 
still [Reproducible] 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 

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 Zirneklītis 2012-10-07 19:14:58 UTC
Created attachment 68222 [details]
Response in terminal
Comment 2 Zirneklītis 2012-10-07 19:16:25 UTC
Comment on attachment 68222 [details]
Response in terminal

LibreOffice
Version 3.6.2.2 (Build ID: da8c1e6)
on
Ubuntu 10.04
Linux 2.6.32-43-generic #97-Ubuntu SMP Wed Sep 5 16:43:09 UTC 2012 i686 GNU/Linux
Comment 3 Michael Meeks 2012-10-08 18:55:23 UTC
==2213== For counts of detected and suppressed errors, rerun with: -v
==2213== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 8)
==2196== Invalid write of size 4
==2196==    at 0x117B988E: XMLTableStyleContext::ApplyCondFormat(com::sun::star::uno::Sequence<com::sun::star::table::CellRangeAddress>) (conditio.hxx:353)
==2196==    by 0x117AC404: ScXMLImport::SetStyleToRanges() (xmlimprt.cxx:2683)
==2196==    by 0x117AC7E5: ScXMLImport::SetStyleToRange(ScRange const&, rtl::OUString const*, short, rtl::OUString const*) (xmlimprt.cxx:2738)
==2196==    by 0x1176F101: ScMyStyleRanges::SetStylesToRanges(std::list<ScRange, std::allocator<ScRange> > const&, rtl::OUString const*, short, rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:182)
==2196==    by 0x1176F36E: ScMyStyleRanges::SetStylesToRanges(rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:191)
==2196==    by 0x1176F7AB: ScMyStylesImportHelper::SetStylesToRanges() (XMLStylesImportHelper.cxx:493)
==2196==    by 0x117BAE1B: ScMyTables::DeleteTable() (xmlsubti.cxx:207)
==2196==    by 0x117BC9A5: ScXMLTableContext::EndElement() (xmltabi.cxx:426)
==2196==    by 0x110DE9F5: SvXMLImport::endElement(rtl::OUString const&) (xmlimp.cxx:716)
==2196==    by 0x113C545C: sax_expatwrap::SaxExpatParser_Impl::callbackEndElement(void*, unsigned short const*) (sax_expat.cxx:817)
==2196==    by 0x113D01CC: doContent (xmlparse.c:2532)
==2196==    by 0x113D073B: contentProcessor (xmlparse.c:2105)
==2196==    by 0x113D1E03: XML_ParseBuffer_UTF16 (xmlparse.c:1651)
==2196==    by 0x113C5C1F: sax_expatwrap::SaxExpatParser_Impl::parse() (sax_expat.cxx:743)
...
==2196==  Address 0xfeac6dc is 4 bytes inside a block of size 44 free'd
==2196==    at 0x4027F33: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2196==    by 0x11686E90: ScTable::AddCondFormat(ScConditionalFormat*) (reversible_ptr_container.hpp:57)
==2196==    by 0x115FA0C8: ScDocument::AddCondFormat(ScConditionalFormat*, short) (documen4.cxx:600)
==2196==    by 0x117B9880: XMLTableStyleContext::ApplyCondFormat(com::sun::star::uno::Sequence<com::sun::star::table::CellRangeAddress>) (xmlstyli.cxx:465)
==2196==    by 0x117AC404: ScXMLImport::SetStyleToRanges() (xmlimprt.cxx:2683)
==2196==    by 0x117AC7E5: ScXMLImport::SetStyleToRange(ScRange const&, rtl::OUString const*, short, rtl::OUString const*) (xmlimprt.cxx:2738)
==2196==    by 0x1176F101: ScMyStyleRanges::SetStylesToRanges(std::list<ScRange, std::allocator<ScRange> > const&, rtl::OUString const*, short, rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:182)
==2196==    by 0x1176F36E: ScMyStyleRanges::SetStylesToRanges(rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:191)
==2196==    by 0x1176F7AB: ScMyStylesImportHelper::SetStylesToRanges() (XMLStylesImportHelper.cxx:493)
==2196==    by 0x117BAE1B: ScMyTables::DeleteTable() (xmlsubti.cxx:207)
==2196==    by 0x117BC9A5: ScXMLTableContext::EndElement() (xmltabi.cxx:426)
==2196==    by 0x110DE9F5: SvXMLImport::endElement(rtl::OUString const&) (xmlimp.cxx:716)
==2196==    by 0x113C545C: sax_expatwrap::SaxExpatParser_Impl::callbackEndElement(void*, unsigned short const*) (sax_expat.cxx:817)
==2196==    by 0x113D01CC: doContent (xmlparse.c:2532)
Comment 4 Michael Meeks 2012-10-08 19:10:12 UTC
*** Bug 55711 has been marked as a duplicate of this bug. ***
Comment 5 Terrence Enger 2012-10-08 19:16:07 UTC
Created attachment 68277 [details]
gdb session, inculding thread apply all backtrace full

While loading the document attached to bug 55584, after displaying an
empty (grey background) document and moving the progress about three
quarters of its width, 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 6 Terrence Enger 2012-10-08 19:17:11 UTC
Created attachment 68278 [details]
copy of terminal output where LO was running
Comment 7 Terrence Enger 2012-10-08 19:56:12 UTC
Created attachment 68281 [details]
valgrind output

Having noticed that the backtraces for both this bug amd bug 55711
have a thread with malloc.c calling __lll_lock_wait_private (), I
tried to run the test case of this bug under valgrind.  
Observations ...

(*) The program offered recovery of document play1.odb.  This is
    surprising because this is a new build in a brand new SRCDIR; this
    LO has never been near play.odb.

(*) After I accepted recovery (that was the only option), the program
    produced the warning from autorecovery.cxx:1198 and terminated.
Comment 8 Markus Mohrhard 2012-10-09 04:40:40 UTC
I'll take a look at it.
Comment 9 Markus Mohrhard 2012-10-09 05:03:12 UTC
Oh this one is a bit embarrassing.

The problem is thaat when we now import the same cond format through two different ranges it is written to the ScConditionalFormatList. Since the conditional format list takes ownership but is a boost::ptr_set inserting it a second time will call delete on the second pointer which is also the first one. Resulting in all the data later on being useless.
Comment 10 Markus Mohrhard 2012-10-09 05:04:53 UTC
*** Bug 55780 has been marked as a duplicate of this bug. ***
Comment 11 Markus Mohrhard 2012-10-09 05:09:33 UTC
*** Bug 55617 has been marked as a duplicate of this bug. ***
Comment 12 Not Assigned 2012-10-09 05:13:25 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

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

don't insert the same data twice into boost::ptr_set, fdo#55710



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 Not Assigned 2012-10-09 07:30:09 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d126dcfe359782a6229156f7cbdb20e642b63a5e&g=libreoffice-3-6

don't insert the same pointer twice into a ptr_set, fdo#55710


It will be available in LibreOffice 3.6.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 14 Michael Meeks 2012-10-09 08:45:07 UTC
Thanks so much for the fix Markus - looks like we're running out of serious cond-format bugs ;-) good work.
Comment 15 Rainer Bielefeld Retired 2012-10-11 05:21:49 UTC
*** Bug 55760 has been marked as a duplicate of this bug. ***
Comment 16 Rainer Bielefeld Retired 2012-10-11 05:40:26 UTC
Works fine with Server Installation of  "LibreOffice  3.6.4.0+  English UI/ German Locale [Build-ID: a4b919d],{tinderbox: Win-x86@9 pull time 2012-10-10 19:11:32}  on German WIN7 Home Premium (64bit). I worked on sample documents for crashes with that Version 1/2 hour intensively without any problems.
Comment 17 Terrence Enger 2012-10-11 12:38:42 UTC
Works on ubuntu-natty (11.04) with master commit 940db0c.

Terry.
Comment 18 Rainer Bielefeld Retired 2012-10-15 19:08:05 UTC
*** Bug 55879 has been marked as a duplicate of this bug. ***