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
Created attachment 68222 [details] Response in terminal
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
==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)
*** Bug 55711 has been marked as a duplicate of this bug. ***
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.
Created attachment 68278 [details] copy of terminal output where LO was running
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.
I'll take a look at it.
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.
*** Bug 55780 has been marked as a duplicate of this bug. ***
*** Bug 55617 has been marked as a duplicate of this bug. ***
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.
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.
Thanks so much for the fix Markus - looks like we're running out of serious cond-format bugs ;-) good work.
*** Bug 55760 has been marked as a duplicate of this bug. ***
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.
Works on ubuntu-natty (11.04) with master commit 940db0c. Terry.
*** Bug 55879 has been marked as a duplicate of this bug. ***