Created attachment 57919 [details] 500 page book Cannot export to PDF.
Confirmed. Tested on Windows XP. LibO 3.5.1 Beta1 crashes while generating the rtf file. LibO 3.4.5 creates the pdf file, but doesn't delete the lock file. (steps: load odt-file, create pdf-file(press pdf button), close LibO (with file/close or with the [x]-button -> lock file will not be deleted) (as lockfile is a hidden file, you must check the option in Windows Explorer that all files should be visible) If I load the file a second time, restore document is necessary. If I delete the lockfile manually than LibO restores the document, loads it and hangs if I try to close LibO (with file/close or with the [x]-button) LibO 3.3.4 works fine, also tested with OOo 3.1, works fine too. This is a regression.
Cant reproduce crash on master (1cf3e446744ae679bc89b39dcbbcf6b4e9821f3a) or 3.5 branch-off (85c6244b85b29c1d2bb9d89b62e9512dd65378b5). Is this Windows-only?
reproduced on windows XP with latest libreoffice-3-5 another windows specific bug - I guess a SEGV; digging into it now ... sal3.dll!_rtl_uString_release() + 0x27 bytes C++ 0000021c() cppuhelper3MSC.dll!com::sun::star::reflection::detail::theXMethodParameterType::operator()() + 0x21c bytes C++ comphelpMSC.dll!comphelper::EnumerableMap::containsValue() + 0x43 bytes C++ comphelpMSC.dll!comphelper::EnumerableMap::containsValue() + 0x43 bytes C++ comphelpMSC.dll!comphelper::EnumerableMap::containsValue() + 0x43 bytes C++ comphelpMSC.dll!comphelper::EnumerableMap::containsValue() + 0x43 bytes C++
Created attachment 58257 [details] hs_err_pid Reproduced on pc Debian x86-64, 3.5 branch (commit : 33ef1ffbd15994ec71be99d38c0d5171c63344a2). Hope it may help.
Created attachment 58259 [details] 2 bt with symbols Fired up gdb and retrieved 2 bts (there was a third and last one but was identical to the second)
Created attachment 58260 [details] new bt after test fix Here's the fix tested : diff --git a/sw/source/core/layout/sectfrm.cxx b/sw/source/core/layout/sectfrm.cxx index 35d38d1..08c0cbe 100644 --- a/sw/source/core/layout/sectfrm.cxx +++ b/sw/source/core/layout/sectfrm.cxx @@ -1382,7 +1382,7 @@ void SwSectionFrm::Format( const SwBorderAttrs *pAttr ) } //Breite der Spalten pruefen und ggf. einstellen. - if ( bHasColumns && ! Lower()->GetNext() && bMaximize ) + if ( bHasColumns && Lower() && ! Lower()->GetNext() && bMaximize ) ((SwColumnFrm*)Lower())->Lower()->Calc(); if ( !bMaximize ) But I had another segv, but now it seems far less obvious :-( (attached the new bt)
Created attachment 58267 [details] 3 bts and hs_error on master I reproduced the pb on master (commit : 137b53e0e2763d41c43e62ecc85b38d7f3cb71f7). I attached on a zip the 3 bts (the 2 last one should be same, like 3.5) + hs_error.pid.
Hi Julien - wow, you did well to reproduce on Linux ! Any chance of a valgrind log from that (it looks like this triggers a set of bugs). My crasher on Windows is: ntdll.dll!_RtlAllocateHeap@12() + 0xe5a bytes msvcr90.dll!_malloc() + 0x79 bytes msvcr90.dll!operator new() + 0x1f bytes vcllo.dll!UniscribeLayout::Simplify(bool __formal=false) Line 2107 + 0x17 bytes C++ vcllo.dll!MultiSalLayout::AdjustLayout(ImplLayoutArgs & rArgs={...}) Line 1672 + 0x8 bytes C++ vcllo.dll!OutputDevice::ImplLayout(const String & rOrigStr={...}, unsigned short nMinIndex=297, unsigned short nLen=55, const Point & rLogicalPos={...}, long nLogicalWidth=0, const long * pDXArray=0x00000000, bool bFilter=false) Line 6070 C++ vcllo.dll!OutputDevice::GetTextArray(const String & rStr={...}, long * pDXAry=0x00000000, unsigned short nIndex=297, unsigned short nLen=55) Line 5724 + 0x1b bytes C++ vcllo.dll!OutputDevice::GetTextWidth(const String & rStr={...}, unsigned short nIndex=297, unsigned short nLen=55) Line 5654 C++ swlo.dll!SwFntObj::GetTextSize(SwDrawTextInfo & rInf={...}) Line 1992 + 0x15 bytes C++ > swlo.dll!SwSubFont::_GetTxtSize(SwDrawTextInfo & rInf={...}) Line 767 + 0x10 bytes C++ swlo.dll!SwFont::_GetTxtSize(SwDrawTextInfo & rInf={...}) Line 344 + 0x20 bytes C++ swlo.dll!SwTxtSizeInfo::GetTxtSize(const SwScriptInfo * pSI=0x0aad2408, const unsigned short nIndex=297, const unsigned short nLength=55, const unsigned short nComp=0, unsigned short & nMinSize=0, unsigned short & nMaxSizeDiff=57906) Line 472 C++ swlo.dll!SwTxtGuess::Guess(const SwTxtPortion & rPor={...}, SwTxtFormatInfo & rInf={...}, const unsigned short nPorHeight=44) Line 520 C++ swlo.dll!SwTxtPortion::_Format(SwTxtFormatInfo & rInf={...}) Line 330 + 0xf bytes C++ swlo.dll!SwTxtPortion::Format(SwTxtFormatInfo & rInf={...}) Line 489 + 0x6 bytes C++ swlo.dll!SwTxtFormatter::BuildPortions(SwTxtFormatInfo & rInf={...}) Line 562 C++ swlo.dll!SwTxtFormatter::FormatLine(const unsigned short nStartPos=279) Line 1553 C++ swlo.dll!SwTxtFrm::FormatLine(SwTxtFormatter & rLine={...}, const unsigned char bPrev=0) Line 1193 C++ swlo.dll!SwTxtFrm::_Format(SwTxtFormatter & rLine={...}, SwTxtFormatInfo & rInf={...}, const unsigned char bAdjust=0) Line 1555 C++ swlo.dll!SwTxtFrm::_Format(SwParaPortion * pPara=0x0aad23c8) Line 1738 C++ swlo.dll!SwTxtFrm::Format(const SwBorderAttrs * __formal=0x00000000) Line 1914 C++ swlo.dll!SwCntntFrm::MakeAll() Line 1446 C++ swlo.dll!SwFrm::PrepareMake() Line 387 C++ swlo.dll!CalcCntnt(SwLayoutFrm * pLay=0x10a2d62c, bool bNoColl=false, bool bNoCalcFollow=false) Line 1604 C++ swlo.dll!SwSectionFrm::_CheckClipping(unsigned char bGrow='Ð', unsigned char bMaximize='') Line 1111 + 0x8 bytes C++ swlo.dll!SwSectionFrm::Format(const SwBorderAttrs * pAttr=0x139de7d4) Line 1380 C++ swlo.dll!SwLayoutFrm::MakeAll() Line 926 C++ swlo.dll!SwSectionFrm::MakeAll() Line 810 C++ swlo.dll!SwFrm::PrepareMake() Line 387 C++ swlo.dll!SwLayAction::FormatLayout(SwLayoutFrm * pLay=0x10a2d62c, unsigned char bAddRect='') Line 1382 C++ swlo.dll!SwLayAction::FormatLayout(SwLayoutFrm * pLay=0x00a2af14, unsigned char bAddRect='') Line 1541 + 0xb bytes C++ swlo.dll!SwLayAction::FormatLayout(SwLayoutFrm * pLay=0x00a13ef4, unsigned char bAddRect='') Line 1541 + 0xb bytes C++ swlo.dll!SwLayAction::InternalAction() Line 696 C++ swlo.dll!SwLayAction::Action() Line 472 C++ swlo.dll!ViewShell::CalcLayout() Line 911 C++ swlo.dll!SwXTextDocument::getRendererCount(const com::sun::star::uno::Any & rSelection={...}, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & rxOptions={...}) Line 2608 C++ Which looks like some font related nasty ...
Created attachment 58382 [details] drmemory log I finally got agood trace o fthe corruption, attached.
Seems like the fix for bug#33090 causes this, it looks like the index we're using into mnGlyphsToChars is in the wrong co-ordinate system (to me). Should it be offset by rVI.mnMinCharPos (ONO) ?
Created attachment 58384 [details] msvc picture ...
It strikes me that UniscribeLayout::Simplify's first block: // prepare for sparse layout // => make sure mpGlyphs2Chars[] exists is a cut/paste job on the same code, that we should prolly unify into some pleasantly named and reasonably comprehensible shared method ;-) mpGlyphs2Chars = new int[ mnGlyphCapacity ]; for( int i = 0; i < mnGlyphCount; ++i ) mpGlyphs2Chars[i] = -1; The initialization of the larger-than-life array surely should go up to mnGlyphCapacity in both cases (though this doesn't fix it either) ;-)
Created attachment 58388 [details] reduced / much smaller test case A much reduced test case, I know now why it took so long to debug; the Greek word at the root is aeon ;-)
It's not that clear to me what's going on here, but tomorrow - if I can, I'll write a unit test based on a OutputDevice::GetTextWidth() call with the magic string from the cut down test case :-)
I believe Caolan's comment in bug#46750 was intended for here: Reverting e601c32661735e9fd78def7ee11bfe21279cca71 reportedly fixed this, so reverted that on 3-5 For master, lets see if e7dc8c652de6babbfc4fe113639c28970af72046 fixes it and retains the fix for bug 33090 So this should be fixed in 3.5.2, thanks !.
*** This bug has been marked as a duplicate of bug 46923 ***
Apparently not a duplicate, and not fixed with Build ID: af67f5f-6845e52-879ce36 from the libreoffice-3-5 branch on windows. Looks like a similar problem, but apparently is not.
Created attachment 59236 [details] PDF export with 3.5 branch With pc Debian x86-64, on 3.5 branch, last commit retrieved 6c6a4ed070acc0b106e951864fa5d20927f5c1e0, I could export to pdf the smallcrash file.
Created attachment 59237 [details] valgrind logs valgrind logs attached with same context than previous comment.
Checked with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce with both test files. Default PDF export settings used.
Created attachment 63983 [details] bt + console msgs on master On pc Debian x86-64, with master sources updated today, I still reproduce the problem. I attached console logs + bt
Looks like a clean NULL ptr de-reference logic bug: #0 0x00007f6f88582740 in SwFrm::GetNext (this=0x0) at /home/julien/compile-libreoffice/libo/sw/source/core/inc/frame.hxx:599 #1 0x00007f6f889b517e in SwSectionFrm::Format (this=0x3e890d0, pAttr=0x4f464b0) at /home/julien/compile-libreoffice/libo/sw/source/core/layout/sectfrm.cxx:1382 #2 0x00007f6f88901927 in SwLayoutFrm::MakeAll (this=0x3e890d0) at /home/julien/compile-libreoffice/libo/sw/source/co Particularly since we seem to check GetNext() and de-reference Lower()->Lower() instead next to it: // Check the width of the columns and adjust if necessary if ( bHasColumns && ! Lower()->GetNext() && bMaximize ) ((SwColumnFrm*)Lower())->Lower()->Calc(); But that's very old code. The valgrind trace is rather more enlightening I guess: Invalid read of size 8 at 0x23F6A0A4: SwFlowFrm::HasFollow() const (in /home/julien/compile-libreoffice/libo_3_5/solver/unxlngx6/lib/libswlo.so) by 0x242A48E1: CalcCntnt(SwLayoutFrm*, bool, bool) (fly.cxx:1787) by 0x2432D92C: SwSectionFrm::_CheckClipping(unsigned char, unsigned char) (sectfrm.cxx:1111) by 0x2432E6B1: SwSectionFrm::Format(SwBorderAttrs const*) (sectfrm.cxx:1379) by 0x242867A6: SwLayoutFrm::MakeAll() (calcmove.cxx:924) by 0x2432C530: SwSectionFrm::MakeAll() (sectfrm.cxx:809) by 0x24283D20: SwFrm::PrepareMake() (calcmove.cxx:386) by 0x23FB8789: SwFrm::Calc() const (frame.hxx:1056) by 0x242D1D77: SwLayAction::FormatLayout(SwLayoutFrm*, unsigned char) (layact.cxx:1381) by 0x242D29F6: SwLayAction::FormatLayout(SwLayoutFrm*, unsigned char) (layact.cxx:1541) by 0x242D29F6: SwLayAction::FormatLayout(SwLayoutFrm*, unsigned char) (layact.cxx:1541) by 0x242CF8FC: SwLayAction::InternalAction() (layact.cxx:695) by 0x242CEE02: SwLayAction::Action() (layact.cxx:471) by 0x24687EDF: ViewShell::CalcLayout() (viewsh.cxx:910) by 0x249F27C0: SwXTextDocument::getRendererCount(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (unotxdoc.cxx:2607) by 0x443FEFD7: PDFExport::Export(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (pdfexport.cxx:864) Address 0x3d9d5e70 is 208 bytes inside a block of size 248 free'd by 0x4A8CE5B: rtl_freeMemory (alloc_global.cxx:348) by 0x4A8F9FF: rtl_cache_free (alloc_cache.cxx:1277) by 0x8D546F7: FixedMemPool::Free(void*) (mempool.cxx:83) by 0x2415C53B: SwSectionFrm::operator delete(void*, unsigned long) (in /home/julien/compile-libreoffice/libo_3_5/solver/unxlngx6/lib/libswlo.so) by 0x2432A254: SwSectionFrm::~SwSectionFrm() (sectfrm.cxx:177) by 0x2433B136: SwLayoutFrm::Destroy() (ssfrm.cxx:606) by 0x2433B383: SwLayoutFrm::~SwLayoutFrm() (ssfrm.cxx:652) by 0x242FD5DE: SwBodyFrm::~SwBodyFrm() (in /home/julien/compile-libreoffice/libo_3_5/solver/unxlngx6/lib/libswlo.so) by 0x242FD61B: SwBodyFrm::~SwBodyFrm() (bodyfrm.hxx:36) by 0x2433B136: SwLayoutFrm::Destroy() (ssfrm.cxx:606) by 0x2433B383: SwLayoutFrm::~SwLayoutFrm() (ssfrm.cxx:652) by 0x2428DD20: SwFtnBossFrm::~SwFtnBossFrm() (in /home/julien/compile-libreoffice/libo_3_5/solver/unxlngx6/lib/libswlo.so) by 0x242F5CBE: SwPageFrm::~SwPageFrm() (pagechg.cxx:279) by 0x242F5D27: SwPageFrm::~SwPageFrm() (pagechg.cxx:327) by 0x242F8CE6: SwFrm::InsertPage(SwPageFrm*, unsigned char) (pagechg.cxx:1360) by 0x2432FA23: SwFrm::GetNextSctLeaf(MakePageType) (sectfrm.cxx:1667) by 0x24298F7A: SwFrm::GetLeaf(MakePageType, unsigned char) (flowfrm.cxx:871) by 0x2429BA2B: SwFlowFrm::MoveFwd(unsigned char, unsigned char, unsigned char) (flowfrm.cxx:1946) by 0x24288086: SwCntntFrm::MakeAll() (calcmove.cxx:1270) by 0x24283A4B: SwFrm::PrepareMake() (calcmove.cxx:318) by 0x23FB8789: SwFrm::Calc() const (frame.hxx:1056) by 0x243D48BB: SwTxtFrm::CalcFollow(unsigned short) (frmform.cxx:315) by 0x243D5A7E: SwTxtFrm::_AdjustFollow(SwTxtFormatter&, unsigned short, unsigned short, unsigned char) (frmform.cxx:607) by 0x243D783A: SwTxtFrm::FormatAdjust(SwTxtFormatter&, WidowsAndOrphans&, unsigned short, unsigned char) (frmform.cxx:1154) by 0x243D6D21: SwTxtFrm::CalcPreps() (frmform.cxx:932) by 0x243D9FE2: SwTxtFrm::Format(SwBorderAttrs const*) (frmform.cxx:1870) by 0x24288FC9: SwCntntFrm::MakeAll() (calcmove.cxx:1427) by 0x24283D20: SwFrm::PrepareMake() (calcmove.cxx:386) by 0x23FB8789: SwFrm::Calc() const (frame.hxx:1056) by 0x242A4099: CalcCntnt(SwLayoutFrm*, bool, bool) (fly.cxx:1601) by 0x2432D92C: SwSectionFrm::_CheckClipping(unsigned char, unsigned char) (sectfrm.cxx:1111) by 0x2432E6B1: SwSectionFrm::Format(SwBorderAttrs const*) (sectfrm.cxx:1379) by 0x242867A6: SwLayoutFrm::MakeAll() (calcmove.cxx:924) by 0x2432C530: SwSectionFrm::MakeAll() (sectfrm.cxx:809) by 0x24283D20: SwFrm::PrepareMake() (calcmove.cxx:386) by 0x23FB8789: SwFrm::Calc() const (frame.hxx:1056) by 0x242D1D77: SwLayAction::FormatLayout(SwLayoutFrm*, unsigned char) (layact.cxx:1381) by 0x242D29F6: SwLayAction::FormatLayout(SwLayoutFrm*, unsigned char) (layact.cxx:1541) by 0x242D29F6: SwLayAction::FormatLayout(SwLayoutFrm*, unsigned char) (layact.cxx:1541) by 0x242CF8FC: SwLayAction::InternalAction() (layact.cxx:695) by 0x242CEE02: SwLayAction::Action() (layact.cxx:471) by 0x24687EDF: ViewShell::CalcLayout() (viewsh.cxx:910) by 0x249F27C0: SwXTextDocument::getRendererCount(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (unotxdoc.cxx:2607) by 0x443FEFD7: PDFExport::Export(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (pdfexport.cxx:864) Which looks much more like a traditional layout / memory mis-management silly.
I can't reproduce this on master, nor on 4.0. Phillip, can you please try again with master or 4.0? If you can no longer reproduce this bug, let's close it. Thanks!
This has been fixed in 4.0, as far as I can tell.
Bisect says this was fixed with 962d0500c4debaef43e5f146e47e08c66d851562. *** This bug has been marked as a duplicate of bug 39510 ***