This one is a spin off from "Bug 54852 - FILEOPEN CRASH for particular .ods". For the sample document Attachment 67087 [details] in that bug the problem really has vanished for "LibreOffice 3.6.2.1 rc English UI/ German Locale [Build-ID: da8c1e6] on German WIN7 Home Premium (64bit) . But unfortunately the problem for my real document persists, I still have lots of spreadsheets what crash when I try to open. That crash is difficult to reproduce, already smaller modifications in the document make the crash disappear. Common for all those documents is that they - have been edited with 3.5.7 or older before I try to open with 3.6.2 - Contain -- Lots of (Conditional) Formatting -- Filters Crash does not appear with 3.6.0.4, I think problem came up with 3.6.1 For me this one has blocker quality. I do not have documents suitable for public use, so I will send one to Markus, who fixed Bug 54498, what might have similar roots.
[Reproducible] with parallel installation of Master "LOdev 3.7.0.0.alpha0+ - ENGLISH UI / German Locale [Build ID: bc63efc]" {tinderbox: @6, pull time 2012-09-24 21:00:28} on German WIN7 Home Premium (64bit)
Rainer, can you e-mail me one of these documents? I will be able to test this with a recent master on openSUSE 11.4 (see if it is system-independent).
Sample document sent by Rainer crashes LO version 3.7.0.0.alpha0+ (Build ID: dccddcc) on openSuSE 11.4 (x86-64) as well.
Status=NEW and Platform=“All” due to comment #3. @Rainer: If you want further cross-platform confirmation, for Mac OS X, you send me one of these documents. I promise to delete it as soon as I have tested it :) Mac OS X will also create a simple stack trace, as a first hint where the problem is.
make debugrun: After loading of file: Program received signal SIGSEGV, Segmentation fault. malloc_consolidate (av=0x7ffff7180e80) at malloc.c:5133 5133 malloc.c: No such file or directory. in malloc.c I probably need to unstall some more debug packages and try again.....
I'd love to have the test document too - it'd be great to check this vs 3.6.2.2 etc.
Created attachment 67762 [details] Mac OS X 10.6.8 log file for LibO 3.6.2.2 crash I can confirm that this crash is REPRODUCIBLE with LibreOffice 3.6.2.2 (Build ID: da8c1e6), German langpack installed, on Mac OS X 10.6.8 (Intel) -- so this is a true cross-platform bug. I can also confirm that this crash does NOT happen with LibreOffice 3.6.0.4 on the same machine, so the bug must have been introduced in between. Attached you find the log file created by Mac OS X for the crash; it includes a simple stack trace (whithout full symbols); I hope this gives a hint where to search ...
Also still REPRODUCIBLE with newest master build: LOdev 3.7.0.0.alpha0+, Build ID: 30d33b1, pull time: 2012-09-27 04:27:30, again on Mac OS X 10.6.8 (Intel). Crash log/stack trace identical to the one for 3.6.2.2.
backtrace after the crash in make debugrun: Program received signal SIGSEGV, Segmentation fault. malloc_consolidate (av=0x7ffff7180e80) at malloc.c:5133 5133 malloc.c: No such file or directory. in malloc.c (gdb) backtrace #0 malloc_consolidate (av=0x7ffff7180e80) at malloc.c:5133 #1 0x00007ffff6e8ce14 in _int_malloc (av=0x7ffff7180e80, bytes=24585) at malloc.c:4367 #2 0x00007ffff6e8e0d2 in malloc_check (sz=24584, caller=<value optimized out>) at hooks.c:264 #3 0x00007ffff76af19d in operator new (sz=24584) at ../../../../libstdc++-v3/libsupc++/new_op.cc:52 #4 0x00007ffff76af2b9 in operator new[] (sz=<value optimized out>) at ../../../../libstdc++-v3/libsupc++/new_opv.cc:32 #5 0x00007fffd41bc15c in ScMarkData::SetMultiMarkArea (this=0x7fffffff29b0, rRange=..., bMark=true) at /home/stephan/Software/libreoffice-master/core/sc/source/core/data/markdata.cxx:133 #6 0x00007fffd41bd67f in ScMarkData::MarkFromRangeList (this=0x7fffffff29b0, rList=..., bReset=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/sc/source/core/data/markdata.cxx:376 #7 0x00007fffd4396b3d in XMLTableStyleContext::ApplyCondFormat (this=0x3052ca0, xCellRanges=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/xmlstyli.cxx:462 #8 0x00007fffd4385520 in ScXMLImport::SetStyleToRanges (this=0x2e88010) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/xmlimprt.cxx:2683 #9 0x00007fffd4385afa in ScXMLImport::SetStyleToRange (this=0x2e88010, rRange=..., pStyleName=0x3256030, nCellType=256, pCurrency=0x0) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/xmlimprt.cxx:2738 #10 0x00007fffd432e116 in ScMyStyleRanges::SetStylesToRanges (this=<value optimized out>, rRanges=..., pStyleName=0x3256030, nCellType=256, pCurrency=0x0, rImport=...) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/XMLStylesImportHelper.cxx:182 #11 0x00007fffd432e700 in ScMyStyleRanges::SetStylesToRanges (this=0x3255f70, pStyleName=0x3256030, rImport=...) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/XMLStylesImportHelper.cxx:198 #12 0x00007fffd432e956 in ScMyStylesImportHelper::SetStylesToRanges (this=0x2edffc0) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/XMLStylesImportHelper.cxx:493 #13 0x00007fffd439ac9a in ScMyTables::DeleteTable (this=0x2e884a8) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/xmlsubti.cxx:207 #14 0x00007fffd439cced in ScXMLTableContext::EndElement (this=0x311dc30) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/xmltabi.cxx:426 #15 0x00007fffde33495e in SvXMLImport::endElement (this=0x2e88010) at /home/stephan/Software/libreoffice-master/core/xmloff/source/core/xmlimp.cxx:716 #16 0x00007fffdf86be7e in sax_expatwrap::SaxExpatParser_Impl::callbackEndElement (pvThis=0x2e70e70, pwName=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/sax/source/expatwrap/sax_expat.cxx:817 #17 0x00007fffdf8811da in doContent (parser=0x2f61490, startTagLevel=0, enc=<value optimized out>, s= 0x2f52bb3 "</table:table><table:table table:name=\"Erledigt\" table:style-name=\"ta1\" table:print=\"false\"><office:forms form:automatic-focus=\"false\" form:apply-design-mode=\"false\"/><table:table-column table:style-n"..., end=<value optimized out>, nextPtr=0x2f614c0, haveMore=1 '\001') at xmlparse.c:2532 #18 0x00007fffdf88217e in contentProcessor (parser=0x2f61490, start=<value optimized out>, end=<value optimized out>, endPtr=<value optimized out>) at xmlparse.c:2105 #19 0x00007fffdf8861dd in XML_ParseBuffer (parser=0x2f61490, len=<value optimized out>, isFinal=0) at xmlparse.c:1651 #20 0x00007fffdf86ca81 in sax_expatwrap::SaxExpatParser_Impl::parse (this=0x2e70e70) at /home/stephan/Software/libreoffice-master/core/sax/source/expatwrap/sax_expat.cxx:743 #21 0x00007fffdf86df8e in sax_expatwrap::SaxExpatParser::parseStream (this=0x2e795a0, structSource=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/sax/source/expatwrap/sax_expat.cxx:531 #22 0x00007fffd43a1268 in ScXMLImportWrapper::ImportFromComponent (this=0x7fffffff3ad0, xServiceFactory= uno::Reference to {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0x7ffff63f2570}, <No data fields>}, xModel= uno::Reference to {<com::sun::star::lang::XComponent> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0x7fffd4b93db0}, <No data fields>}, <No data fields>}, xXMLParser=uno::Reference to {_vptr.XInterface = 0x7fffdfaa9e30}, aParserInput=..., sComponentName=..., sDocName=..., sOldDocName=..., aArgs=uno::Sequence of length 4 = {...}, bMustBeSuccessfull=1 '\001') at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/xmlwrap.cxx:192 #23 0x00007fffd43a36b8 in ScXMLImportWrapper::Import (this=0x7fffffff3ad0, bStylesOnly=0 '\000', nError=@0x7fffffff3b30) at /home/stephan/Software/libreoffice-master/core/sc/source/filter/xml/xmlwrap.cxx:523 #24 0x00007fffd4470461 in ScDocShell::LoadXML (this=0x2e0b000, pLoadMedium=0x2d41b70, xStor=empty uno::Reference) at /home/stephan/Software/libreoffice-master/core/sc/source/ui/docshell/docsh.cxx:430 #25 0x00007fffd4470b7b in ScDocShell::Load (this=0x2e0b000, rMedium=...) at /home/stephan/Software/libreoffice-master/core/sc/source/ui/docshell/docsh.cxx:502 #26 0x00007ffff570968a in SfxObjectShell::LoadOwnFormat (this=0x2e0b000, rMedium=...) at /home/stephan/Software/libreoffice-master/core/sfx2/source/doc/objstor.cxx:2978 #27 0x00007ffff5710333 in SfxObjectShell::DoLoad (this=0x2e0b000, pMed=0x2d41b70) at /home/stephan/Software/libreoffice-master/core/sfx2/source/doc/objstor.cxx:675 #28 0x00007ffff574276e in SfxBaseModel::load (this=0x2bad230, seqArguments=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/sfx2/source/doc/sfxbasemodel.cxx:1899 #29 0x00007ffff579b4f0 in SfxFrameLoader_Impl::load (this=0x2d69180, rArgs=<value optimized out>, _rTargetFrame= uno::Reference to {<com::sun::star::lang::XComponent> = {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0x7fffe1c17890}, <No data fields>}, <No data fields>}) at /home/stephan/Software/libreoffice-master/core/sfx2/source/view/frmload.cxx:598 #30 0x00007fffe183b086 in framework::LoadEnv::impl_loadContent (this=0x2ae8238) at /home/stephan/Software/libreoffice-master/core/framework/source/loadenv/loadenv.cxx:1147 #31 0x00007fffe183d2d0 in framework::LoadEnv::startLoading (this=0x2ae8238) at /home/stephan/Software/libreoffice-master/core/framework/source/loadenv/loadenv.cxx:408 #32 0x00007fffe17b0e33 in framework::LoadDispatcher::impl_dispatch (this=0x2ae81a0, rURL=..., lArguments=uno::Sequence of length 6 = {...}, xListener=empty uno::Reference) at /home/stephan/Software/libreoffice-master/core/framework/source/dispatch/loaddispatcher.cxx:130 #33 0x00007fffe17b1348 in framework::LoadDispatcher::dispatchWithReturnValue (this=<value optimized out>, rURL=<value optimized out>, lArguments=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/framework/source/dispatch/loaddispatcher.cxx:76 #34 0x00007ffff6761205 in comphelper::SynchronousDispatch::dispatch (xStartPoint=<value optimized out>, sURL=<value optimized out>, sTarget=..., nFlags=<value optimized out>, lArguments=uno::Sequence of length 6 = {...}) at /home/stephan/Software/libreoffice-master/core/comphelper/source/misc/synchronousdispatch.cxx:73 #35 0x00007ffff550e472 in SfxApplication::OpenDocExec_Impl (this=<value optimized out>, rReq=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/sfx2/source/appl/appopen.cxx:1203 ---Type <return> to continue, or q <return> to quit--- #36 0x00007ffff57da77c in SfxShell::CallExec (this=0x12270d0, pFunc=0x7ffff55086d0 <SfxStubSfxApplicationOpenDocExec_Impl(SfxShell*, SfxRequest&)>, rReq=...) at /home/stephan/Software/libreoffice-master/core/sfx2/inc/sfx2/shell.hxx:188 #37 0x00007ffff57d4103 in SfxDispatcher::Call_Impl (this=0x123bf90, rShell=..., rSlot=..., rReq=..., bRecord=0 '\000') at /home/stephan/Software/libreoffice-master/core/sfx2/source/control/dispatch.cxx:249 #38 0x00007ffff57d5af5 in SfxDispatcher::_Execute (this=0x123bf90, rShell=..., rSlot=..., rReq=..., eCallMode=1) at /home/stephan/Software/libreoffice-master/core/sfx2/source/control/dispatch.cxx:932 #39 0x00007ffff57d6490 in SfxDispatcher::Execute (this=0x123bf90, nSlot=5501, eCall=1, nModi=0, rArgs=...) at /home/stephan/Software/libreoffice-master/core/sfx2/source/control/dispatch.cxx:1134 #40 0x00007ffff57d62f1 in SfxDispatcher::Execute (this=0x123bf90, nSlot=5501, eCall=1, rArgs=...) at /home/stephan/Software/libreoffice-master/core/sfx2/source/control/dispatch.cxx:1106 #41 0x00007ffff550f021 in SfxApplication::OpenDocExec_Impl (this=0x12270d0, rReq=...) at /home/stephan/Software/libreoffice-master/core/sfx2/source/appl/appopen.cxx:835 #42 0x00007ffff57da77c in SfxShell::CallExec (this=0x12270d0, pFunc=0x7ffff55086d0 <SfxStubSfxApplicationOpenDocExec_Impl(SfxShell*, SfxRequest&)>, rReq=...) at /home/stephan/Software/libreoffice-master/core/sfx2/inc/sfx2/shell.hxx:188 #43 0x00007ffff57d4103 in SfxDispatcher::Call_Impl (this=0x123bf90, rShell=..., rSlot=..., rReq=..., bRecord=1 '\001') at /home/stephan/Software/libreoffice-master/core/sfx2/source/control/dispatch.cxx:249 #44 0x00007ffff57d690c in SfxDispatcher::PostMsgHandler (this=0x123bf90, pReq=0x2ca7630) at /home/stephan/Software/libreoffice-master/core/sfx2/source/control/dispatch.cxx:1234 #45 0x00007ffff57d67f9 in SfxDispatcher::LinkStubPostMsgHandler (pThis=0x123bf90, pCaller=0x2ca7630) at /home/stephan/Software/libreoffice-master/core/sfx2/source/control/dispatch.cxx:1205 #46 0x00007ffff577f78a in DoEvent_Impl (pThis=<value optimized out>, pCaller=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/sfx2/source/notify/hintpost.cxx:52 #47 SfxHintPoster::LinkStubDoEvent_Impl (pThis=<value optimized out>, pCaller=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/sfx2/source/notify/hintpost.cxx:56 #48 0x00007ffff37a55c8 in Call (pWindow=<value optimized out>, nEvent=<value optimized out>, pEvent=0x2ca9af0) at /home/stephan/Software/libreoffice-master/core/solver/unxlngx6.pro/inc/tools/link.hxx:123 #49 ImplHandleUserEvent (pWindow=<value optimized out>, nEvent=<value optimized out>, pEvent=0x2ca9af0) at /home/stephan/Software/libreoffice-master/core/vcl/source/window/winproc.cxx:1997 #50 ImplWindowFrameProc (pWindow=<value optimized out>, nEvent=<value optimized out>, pEvent=0x2ca9af0) at /home/stephan/Software/libreoffice-master/core/vcl/source/window/winproc.cxx:2569 #51 0x00007ffff37ae70d in CallCallback (this=0x651430) at /home/stephan/Software/libreoffice-master/core/vcl/inc/salframe.hxx:278 #52 SalGenericDisplay::DispatchInternalEvent (this=0x651430) at /home/stephan/Software/libreoffice-master/core/vcl/generic/app/gendisp.cxx:102 #53 0x00007fffe8786082 in GtkData::userEventFn (data=0x617dd0) at /home/stephan/Software/libreoffice-master/core/vcl/unx/gtk/app/gtkdata.cxx:954 #54 0x00007fffe8786109 in call_userEventFn (data=0x617dd0) at /home/stephan/Software/libreoffice-master/core/vcl/unx/gtk/app/gtkdata.cxx:964 #55 0x00007ffff2692bd3 in g_main_dispatch (context=0x64ff50) at gmain.c:2440 #56 g_main_context_dispatch (context=0x64ff50) at gmain.c:3013 #57 0x00007ffff26933b0 in g_main_context_iterate (context=0x64ff50, block=0, dispatch=1, self=<value optimized out>) at gmain.c:3091 #58 0x00007ffff2693650 in g_main_context_iteration (context=0x64ff50, may_block=0) at gmain.c:3154 #59 0x00007fffe8785dfd in GtkData::Yield (this=0x617dd0, bWait=true, bHandleAllCurrentEvents=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/vcl/unx/gtk/app/gtkdata.cxx:591 #60 0x00007ffff34e2431 in ImplYield (i_bAllEvents=false) at /home/stephan/Software/libreoffice-master/core/vcl/source/app/svapp.cxx:434 #61 Application::Yield (i_bAllEvents=false) at /home/stephan/Software/libreoffice-master/core/vcl/source/app/svapp.cxx:468 #62 0x00007ffff34e24e7 in Application::Execute () at /home/stephan/Software/libreoffice-master/core/vcl/source/app/svapp.cxx:413 #63 0x00007ffff791d0ca in desktop::Desktop::Main (this=0x7fffffff7500) at /home/stephan/Software/libreoffice-master/core/desktop/source/app/app.cxx:1714 #64 0x00007ffff34eaf61 in ImplSVMain () at /home/stephan/Software/libreoffice-master/core/vcl/source/app/svmain.cxx:173 #65 0x00007ffff34eafd5 in SVMain () at /home/stephan/Software/libreoffice-master/core/vcl/source/app/svmain.cxx:210 #66 0x00007ffff79536fd in soffice_main () at /home/stephan/Software/libreoffice-master/core/desktop/source/app/sofficemain.cxx:83 #67 0x00000000004007ab in sal_main (argc=<value optimized out>, argv=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/desktop/source/app/main.c:25 #68 main (argc=<value optimized out>, argv=<value optimized out>) at /home/stephan/Software/libreoffice-master/core/desktop/source/app/main.c:24
More useful is the valgrind trace with symbols (I suspect); Markus ? :-) ==4654== Invalid read of size 4 ==4654== at 0x10C1FF42: XMLTableStyleContext::ApplyCondFormat(com::sun::star::uno::Sequence<com::sun::star::table::CellRangeAddress>) (xmlstyli.cxx:1048) ==4654== by 0x10C12B34: ScXMLImport::SetStyleToRanges() (xmlimprt.cxx:2683) ==4654== by 0x10C12F15: ScXMLImport::SetStyleToRange(ScRange const&, rtl::OUString const*, short, rtl::OUString const*) (xmlimprt.cxx:2738) ==4654== by 0x10BD578D: ScMyStyleRanges::SetStylesToRanges(std::list<ScRange, std::allocator<ScRange> > const&, rtl::OUString const*, short, rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:182) ==4654== by 0x10BD5A4D: ScMyStyleRanges::SetStylesToRanges(rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:198) ==4654== by 0x10BD5E37: ScMyStylesImportHelper::SetStylesToRanges() (XMLStylesImportHelper.cxx:493) ==4654== by 0x10C21753: ScMyTables::DeleteTable() (xmlsubti.cxx:207) ==4654== by 0x10C232E1: ScXMLTableContext::EndElement() (xmltabi.cxx:426) ==4654== by 0x1011ACD5: SvXMLImport::endElement(rtl::OUString const&) (xmlimp.cxx:716) ==4654== by 0x104113FE: sax_expatwrap::SaxExpatParser_Impl::callbackEndElement(void*, unsigned short const*) (sax_expat.cxx:817) ==4654== by 0x1041C170: doContent (xmlparse.c:2532) ==4654== by 0x1041C6DF: contentProcessor (xmlparse.c:2105) ==4654== Address 0xec8f6a4 is 4 bytes inside a block of size 44 free'd ==4654== at 0x4027F33: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==4654== by 0x10C12B34: ScXMLImport::SetStyleToRanges() (xmlimprt.cxx:2683) ==4654== by 0x10C12F15: ScXMLImport::SetStyleToRange(ScRange const&, rtl::OUString const*, short, rtl::OUString const*) (xmlimprt.cxx:2738) ==4654== by 0x10BD578D: ScMyStyleRanges::SetStylesToRanges(std::list<ScRange, std::allocator<ScRange> > const&, rtl::OUString const*, short, rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:182) ==4654== by 0x10BD5A4D: ScMyStyleRanges::SetStylesToRanges(rtl::OUString const*, ScXMLImport&) (XMLStylesImportHelper.cxx:198) ==4654== by 0x10BD5E37: ScMyStylesImportHelper::SetStylesToRanges() (XMLStylesImportHelper.cxx:493) ==4654== by 0x10C21753: ScMyTables::DeleteTable() (xmlsubti.cxx:207) ==4654== by 0x10C232E1: ScXMLTableContext::EndElement() (xmltabi.cxx:426) ==4654== by 0x1011ACD5: SvXMLImport::endElement(rtl::OUString const&) (xmlimp.cxx:716) ==4654== by 0x104113FE: sax_expatwrap::SaxExpatParser_Impl::callbackEndElement(void*, unsigned short const*) (sax_expat.cxx:817) ==4654== by 0x1041C170: doContent (xmlparse.c:2532) ==4654== by 0x1041C6DF: contentProcessor (xmlparse.c:2105)
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5d4e2cf96e5c28634ed6968f87b476e8a2a5850 fetime of mpCondFormat is more complex, fdo#55379 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.
Ok the problem here is the lifetime of mpCondFormat. The "insane" style import code imports the cond format with two different ranges two times in this document. So during the second time we were deleting the object which is already owned by the ptr_set in ScConditionalFormatList. Normally the style import code should have merged these two ranges earlier and only import them once but who knows where this corner case is hidden. I have no idea how to create such a document from scratch so I will create such a document for the automated tests by manipulating the xml file directly and hope that normally should import these two ranges as one range list will not merge them in my test document.
Thanks Markus; picked to -3-6 & closed.
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=2ec30db5f8a9b629b3a099ed8e4d3598567feceb&g=libreoffice-3-6 fetime of mpCondFormat is more complex, fdo#55379 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.
CRASH is still [Reproducible] with parallel installation of Master "LOdev 3.7.0.0.alpha0+ - ENGLISH UI / German Locale [Build ID: c7e559]" {tinderbox: @16, pull time 2012-10-03 05:46:26} on German WIN7 Home Premium (64bit), I will do a second test with a later version before I reopen. May be there is an additional crash reason?
CRASH is still [Reproducible] with "SampleDocumentNotForPublicUse.ods" and Server Installation of "LibreOffice 3.6.3.0+ English UI/ German Locale [Build-ID: 1e73405] on German WIN7 Home Premium (64bit) {tinderbox: Win-x86@9, pull time 2012-10-05 15:31:15} "Bug 55633 - CRASH when FILEOPEN particular .ODS" looks similar, I will send a sample document to Markus. @Markus: Can you please check whether fix does not solve the complete problem or whether the document contains a second crash reason (and in this case close this one and open a separate bug)?
Created attachment 68165 [details] Mac OS X 10.6.8 log file for LOdev 3.7 2012-10-04 CRASH is also still REPRODUCIBLE on Mac OS X (10.6.8, Intel) with LOdev 3.7.0.0.alpha0+ (Build ID: dd11a1e, pull time: 2012-10-04 12:52:50). Please find the (simple) stack trace attached.
Created attachment 68166 [details] Mac OS X 10.6.8 log file for LOdev 3.7 2012-10-04 That was the wrong log file, sorry, replaced. Please note the little difference to the 3.6.2.2 stack trace.
Created attachment 68167 [details] Mac OS X 10.6.8 log file for LOdev 3.7 2012-10-04, Variant Interesting enough, if I repeat the test (just opening the file with LOdev 2012-10-04) for some times, I get sometimes a different crash log/stack trace; I attach an example of the other type with a much shorter stack trace. I do not know what this difference (different stack traces for exactly the same action) means, but probably some developer will tell us ;-)
Created attachment 68168 [details] Mac OS X 10.6.8 log file for LOdev 3.7 2012-10-04, Variant I am an complete idiot today, and always attach the wrong log file. Sorry! Fortunately I can blame it on the cold I have got -- Fortunately should stay in bed instead of irritating other people with silly errors in bug wrangling ... Sorry again!
*** Bug 55633 has been marked as a duplicate of this bug. ***
Lets mark this bug as fixed again. Personally I prefer if bug reports are not reopened if is not 100% sure that they are related. Normally this bug report should now both being closed as RESOLVED/FIXED and as DUPLICATE of Bug 55710.
(In reply to comment #22) > Lets mark this bug as fixed again. Personally I prefer if bug reports are > not reopened if is not 100% sure that they are related. Sorry, but I don’t understand your argument. I did *not* open this bug again because I think it is related to some other one, but just because Rainer (comment #15 and #16) and me could still reproduce exactly *this* bug; so the crash was just not fixed, notwithstanding your patch has fixed an important problem (thank you very much for that!) ... The only possibility I can think of is that, as Rainer suggested, “the document contains a second crash reason” (comment #16). If this is true, please state so explicitly, then we can agree that this “second crash reason” should be handled as bug 55710. Thank you very much! > Normally this bug report should now both being closed as RESOLVED/FIXED and > as DUPLICATE of Bug 55710. Doing both at the same time is impossible ;-) Is this a typo, and did you mean “and [bug 55633 should be marked] as a DUPLICATE of bug 55710 [instead]”? Given the possibility mentioned above, this seems a good solution, and I will do so, in the hope that I understand you correctly.
(In reply to comment #23) > (In reply to comment #22) > > Lets mark this bug as fixed again. Personally I prefer if bug reports are > > not reopened if is not 100% sure that they are related. > > Sorry, but I don’t understand your argument. I did *not* open this bug again > because I think it is related to some other one, but just because Rainer > (comment #15 and #16) and me could still reproduce exactly *this* bug; so > the crash was just not fixed, notwithstanding your patch has fixed an > important problem (thank you very much for that!) ... > > The only possibility I can think of is that, as Rainer suggested, “the > document contains a second crash reason” (comment #16). If this is true, > please state so explicitly, then we can agree that this “second crash > reason” should be handled as bug 55710. Thank you very much! This was a different bug. You can belive me that when I commit a fix for a crash and it still crashes this means that in 99% there is another bug. The second bug was a bit trickier and did not show up in a normal build for me only in a dbgutil build. At least for crashes I think it is a safe assumption that when a develoeprs marks it as fixed and there are still problems around it that opening a new bug report and cc'ing the developer is the better alternative. For example I'm cc'd and assigned to quite a lot of calc bugs and filter more or less all noise that comes from bug reports where I know they are surely fixed. > > > > Normally this bug report should now both being closed as RESOLVED/FIXED and > > as DUPLICATE of Bug 55710. > > Doing both at the same time is impossible ;-) Is this a typo, and did you > mean “and [bug 55633 should be marked] as a DUPLICATE of bug 55710 > [instead]”? Given the possibility mentioned above, this seems a good > solution, and I will do so, in the hope that I understand you correctly. I know that it is not possible which is the problem here. This bug contains now discussions for two bugs with the same symptom but different fixes. My comment was mainly a suggestion to the QA guys who do an amazing job and therefore it is sad if through such problems are hidden behind the normal "noise". If I (and most likely most of the remaining developers ) are set into cc of a bug we at least will have a quick look at the bug report whereas reopening a bug report might go unnoticed if that bug (in the code) is surely gone. Thanks anyway for triaging this bug.
@ Markus Mohrhard: Thank you for clarification!
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.