Bug 46896 - File crashes when exporting to PDF.
Summary: File crashes when exporting to PDF.
Status: RESOLVED DUPLICATE of bug 39510
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All Windows (All)
: medium major
Assignee: Miklos Vajna
URL:
Whiteboard: bibisected35 bibisected35newer
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-03-02 06:55 UTC by Phillip Ross
Modified: 2013-08-15 20:07 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
500 page book (1.23 MB, application/vnd.oasis.opendocument.text)
2012-03-02 06:55 UTC, Phillip Ross
Details
hs_err_pid (118.26 KB, text/x-log)
2012-03-09 16:12 UTC, Julien Nabet
Details
2 bt with symbols (5.34 KB, application/zip)
2012-03-09 16:38 UTC, Julien Nabet
Details
new bt after test fix (10.54 KB, text/plain)
2012-03-09 16:49 UTC, Julien Nabet
Details
3 bts and hs_error on master (23.80 KB, application/zip)
2012-03-10 04:32 UTC, Julien Nabet
Details
drmemory log (12.07 KB, text/plain)
2012-03-13 09:55 UTC, Michael Meeks
Details
msvc picture ... (167.54 KB, image/png)
2012-03-13 10:23 UTC, Michael Meeks
Details
reduced / much smaller test case (18.30 KB, application/vnd.oasis.opendocument.text)
2012-03-13 11:05 UTC, Michael Meeks
Details
PDF export with 3.5 branch (30.28 KB, application/pdf)
2012-03-29 12:29 UTC, Julien Nabet
Details
valgrind logs (51.49 KB, application/x-gzip)
2012-03-29 13:17 UTC, Julien Nabet
Details
bt + console msgs on master (10.79 KB, text/plain)
2012-07-08 12:44 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phillip Ross 2012-03-02 06:55:13 UTC
Created attachment 57919 [details]
500 page book

Cannot export to PDF.
Comment 1 s-joyemusequna 2012-03-03 01:04:30 UTC
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.
Comment 2 Björn Michaelsen 2012-03-09 01:21:54 UTC
Cant reproduce crash on master (1cf3e446744ae679bc89b39dcbbcf6b4e9821f3a) or 3.5 branch-off (85c6244b85b29c1d2bb9d89b62e9512dd65378b5). Is this Windows-only?
Comment 3 Michael Meeks 2012-03-09 09:39:59 UTC
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++
Comment 4 Julien Nabet 2012-03-09 16:12:40 UTC
Created attachment 58257 [details]
hs_err_pid

Reproduced on pc Debian x86-64, 3.5 branch (commit : 33ef1ffbd15994ec71be99d38c0d5171c63344a2).
Hope it may help.
Comment 5 Julien Nabet 2012-03-09 16:38:55 UTC
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)
Comment 6 Julien Nabet 2012-03-09 16:49:37 UTC
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)
Comment 7 Julien Nabet 2012-03-10 04:32:30 UTC
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.
Comment 8 Michael Meeks 2012-03-13 05:59:46 UTC
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 ...
Comment 9 Michael Meeks 2012-03-13 09:55:46 UTC
Created attachment 58382 [details]
drmemory log

I finally got  agood trace o fthe corruption, attached.
Comment 10 Michael Meeks 2012-03-13 10:22:42 UTC
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) ?
Comment 11 Michael Meeks 2012-03-13 10:23:47 UTC
Created attachment 58384 [details]
msvc picture ...
Comment 12 Michael Meeks 2012-03-13 10:43:07 UTC
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) ;-)
Comment 13 Michael Meeks 2012-03-13 11:05:40 UTC
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 ;-)
Comment 14 Michael Meeks 2012-03-13 11:18:28 UTC
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 :-)
Comment 15 Michael Meeks 2012-03-20 07:20:36 UTC
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 !.
Comment 16 Caolán McNamara 2012-03-21 04:57:35 UTC

*** This bug has been marked as a duplicate of bug 46923 ***
Comment 17 Michael Meeks 2012-03-27 06:41:55 UTC
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.
Comment 18 Julien Nabet 2012-03-29 12:29:10 UTC
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.
Comment 19 Julien Nabet 2012-03-29 13:17:34 UTC
Created attachment 59237 [details]
valgrind logs

valgrind logs attached with same context than previous comment.
Comment 20 bfoman (inactive) 2012-06-04 04:47:41 UTC
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.
Comment 21 Julien Nabet 2012-07-08 12:44:24 UTC
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
Comment 22 Michael Meeks 2012-12-21 16:29:02 UTC
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.
Comment 23 Miklos Vajna 2013-04-02 15:38:18 UTC
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!
Comment 24 Phillip Ross 2013-04-02 16:14:40 UTC
This has been fixed in 4.0, as far as I can tell.
Comment 25 Miklos Vajna 2013-08-07 09:17:41 UTC
Bisect says this was fixed with 962d0500c4debaef43e5f146e47e08c66d851562.

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