Bug 680365 - segmentation fault (core dumped) "$sd_prog/$sd_binary" "$@" in OpenOffice Writer
Summary: segmentation fault (core dumped) "$sd_prog/$sd_binary" "$@" in OpenOffice Wr...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: 14
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Stahl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-25 09:23 UTC by bethebeast
Modified: 2011-10-28 16:15 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-28 16:15:35 UTC
Type: ---


Attachments (Terms of Use)
strace soffice -writer &> writer_crash (24.87 KB, text/plain)
2011-02-25 09:23 UTC, bethebeast
no flags Details

Description bethebeast 2011-02-25 09:23:58 UTC
Created attachment 480962 [details]
strace soffice -writer &> writer_crash

Description of problem:

When i try ti print, or export in PDF a specific .odt file, i get this crash.

I try with other document, but it only crash with this one :

http://lkco.gezen.fr/FAN/FAN_Documentation_FR_v1.1.odt

Attached bellow the strace.


Version-Release number of selected component (if applicable):

rpm -qa |grep openoffice
openoffice.org-extendedPDF-1.4-10.fc14.x86_64
openoffice.org-opensymbol-fonts-3.3.0-20.2.fc14.noarch
openoffice.org-writer-3.3.0-20.2.fc14.x86_64
openoffice.org-base-3.3.0-20.2.fc14.x86_64
openoffice.org-calc-core-3.3.0-20.2.fc14.x86_64
openoffice.org-langpack-fr-3.3.0-20.2.fc14.x86_64
openoffice.org-impress-core-3.3.0-20.2.fc14.x86_64
openoffice.org-report-builder-3.3.0-20.2.fc14.x86_64
openoffice.org-presenter-screen-3.3.0-20.2.fc14.x86_64
openoffice.org-math-3.3.0-20.2.fc14.x86_64
openoffice.org-pyuno-3.3.0-20.2.fc14.x86_64
openoffice.org-ure-3.3.0-20.2.fc14.x86_64
openoffice.org-core-3.3.0-20.2.fc14.x86_64
openoffice.org-draw-core-3.3.0-20.2.fc14.x86_64
openoffice.org-calc-3.3.0-20.2.fc14.x86_64
openoffice.org-langpack-en-3.3.0-20.2.fc14.x86_64
openoffice.org-brand-3.3.0-20.2.fc14.x86_64
openoffice.org-pdfimport-3.3.0-20.2.fc14.x86_64
openoffice.org-impress-3.3.0-20.2.fc14.x86_64
openoffice.org-xsltfilter-3.3.0-20.2.fc14.x86_64
openoffice.org-base-core-3.3.0-20.2.fc14.x86_64
openoffice.org-graphicfilter-3.3.0-20.2.fc14.x86_64
openoffice.org-draw-3.3.0-20.2.fc14.x86_64
openoffice.org-writer-core-3.3.0-20.2.fc14.x86_64
openoffice.org-math-core-3.3.0-20.2.fc14.x86_64
openoffice.org-emailmerge-3.3.0-20.2.fc14.x86_64



How reproducible:


Steps to Reproduce:
1. open the document FAN_Documentation_FR_v1.1.odt
2. try to print the file or export it in PDF
3. get crash
  
Actual results:


Expected results:


Additional info:

Comment 1 David Tardon 2011-02-26 08:14:49 UTC
reproducible

Comment 2 Michael Stahl 2011-10-27 09:29:36 UTC
==4657== Invalid read of size 8
==4657==    at 0x2C013DA2: SwRect::operator=(SwRect const&) (swrect.hxx:265)
==4657==    by 0x2C76F110: SetSwVisArea(ViewShell*, SwRect const&, unsigned char) (vprint.cxx:197)
==4657==    by 0x2C7708D0: ViewShell::PrintOrPDFExport(OutputDevice*, SwPrintData const&, int) (vprint.cxx:510)
==4657==    by 0x2CABF400: SwXTextDocument::render(int, com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (unotxdoc.cxx:2943)
==4657==    by 0x6A6C21C: SfxPrinterController::printPage(int) const (viewprn.cxx:273)
==4657==    by 0x95C61A7: vcl::PrinterController::getPageFile(int, GDIMetaFile&, bool) (print3.cxx:881)
==4657==    by 0x95C6731: vcl::PrinterController::getFilteredPageFile(int, GDIMetaFile&, bool) (print3.cxx:953)
==4657==    by 0x95C7772: vcl::PrinterController::printFilteredPage(int) (print3.cxx:1144)
==4657==    by 0x95C4D50: Printer::StartJob(rtl::OUString const&, boost::shared_ptr<vcl::PrinterController>&) (print3.cxx:625)
[...]
==4657==  Address 0x1e483df0 is 112 bytes inside a block of size 224 free'd
==4657==    at 0x4A0662E: free (vg_replace_malloc.c:366)
==4657==    by 0x4C70758: rtl_freeMemory_SYSTEM (in /data/lo/core/solver/unxlngx6/lib/libuno_sal.so.3)
==4657==    by 0x4C7086A: rtl_freeMemory (in /data/lo/core/solver/unxlngx6/lib/libuno_sal.so.3)
==4657==    by 0x4C733A2: rtl_cache_free (in /data/lo/core/solver/unxlngx6/lib/libuno_sal.so.3)
==4657==    by 0x858BD73: FixedMemPool::Free(void*) (mempool.cxx:85)
==4657==    by 0x2C3A8FDA: SwPageFrm::operator delete(void*, unsigned long) (in /data/lo/core/solver/unxlngx6/lib/libswlo.so)
==4657==    by 0x2C3DF410: SwPageFrm::~SwPageFrm() (pagechg.cxx:329)
==4657==    by 0x2C3E2AD4: SwRootFrm::RemoveSuperfluous() (pagechg.cxx:1533)
==4657==    by 0x2C3B7271: SwLayAction::InternalAction() (layact.cxx:635)
==4657==    by 0x2C3B6A28: SwLayAction::Action() (layact.cxx:468)
==4657==    by 0x2C3F2807: SwRootFrm::Paint(SwRect const&, SwPrintData const*) const (paintfrm.cxx:2826)
==4657==    by 0x2C77096A: ViewShell::PrintOrPDFExport(OutputDevice*, SwPrintData const&, int) (vprint.cxx:530)
==4657==    by 0x2CABF400: SwXTextDocument::render(int, com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (unotxdoc.cxx:2943)
==4657==    by 0x6A6C21C: SfxPrinterController::printPage(int) const (viewprn.cxx:273)
==4657==    by 0x95C61A7: vcl::PrinterController::getPageFile(int, GDIMetaFile&, bool) (print3.cxx:881)
==4657==    by 0x95C6731: vcl::PrinterController::getFilteredPageFile(int, GDIMetaFile&, bool) (print3.cxx:953)
==4657==    by 0x95C7772: vcl::PrinterController::printFilteredPage(int) (print3.cxx:1144)
==4657==    by 0x95C4D50: Printer::StartJob(rtl::OUString const&, boost::shared_ptr<vcl::PrinterController>&) (print3.cxx:625)
==4657==    by 0x95C41FE: Printer::ImplPrintJob(boost::shared_ptr<vcl::PrinterController> const&, JobSetup const&) (print3.cxx:470)
==4657==    by 0x95C3464: PrintJobAsync::ExecJob(void*) (print3.cxx:280)

the problem here is that the page frame of the last page gets deleted while the document is being printed.

this can be seen also when opening the bugdoc and waiting a bit: it shrinks from 58 pages to (eventually) 55 pages.  (an OOO340 build behaves the same).

actually i'd say there are 3 problems here:
1. the document takes too long to be formatted
2. the document is being reformatted while printing is in progress
3. the printing code retains bare C++ pointers to layout frames

re 3.:

  class SwRenderData
  {
  [...]
      std::map< sal_Int32, const SwPageFrm * >    m_aValidStartFrames;    // the map of start frames for those pages


this map is filled by SwXTextDocument::getRendererCount() with the page frames of the selected pages.
then SwXTextDocument::render() takes one page out of the map and prints it.

this is already pretty insane because of course layout frames are not refcounted and this is basically UNO API and anything could happen between calls to getRendererCount() and render().

guess this could be fixed either by attaching some listener to the page frames (but currently they don't derive from SwModify), or by not retaining the pointers and just walking the SwRootFrm::GetLower() list for every page (which is of course slower but should not crash).

Comment 3 Michael Stahl 2011-10-28 15:57:28 UTC
fixed problem #3 upstream on master:

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

the bugdoc no longer crashes on printing, instead i get these neat assertions:

Error: ERROR: SwPageFrm expected From File /data/lo/core/sw/source/core/view/vprint.cxx at Line 454
Error: non-existent page requested From File /data/lo/core/sw/source/core/view/vprint.cxx at Line 455
Error: failed to get start page From File /data/lo/core/sw/source/core/view/vprint.cxx at Line 543

Comment 4 Michael Stahl 2011-10-28 16:15:35 UTC
currently i don't think this bug is so easy to hit:
before printing the entire document is re-layouted,
so you have to have a "very special" document to actually get a crash.

so i will close this as UPSTREAM, probably F17 will get the fixed upstream release.

if duplicate crash reports turn up backporting the fix may be considered.


Note You need to log in before you can comment on or make changes to this bug.