Bug 62111 - FILESAVE Libreoffice hangs when exporting a particular .ods to .xlsx
Summary: FILESAVE Libreoffice hangs when exporting a particular .ods to .xlsx
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: Other All
: medium major
Assignee: Noel Power
URL:
Whiteboard: target:4.1.0 target:4.0.2
Keywords:
: 62430 (view as bug list)
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2013-03-10 15:47 UTC by Rainer Bielefeld Retired
Modified: 2013-10-04 20:07 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2013-03-10 15:47:24 UTC
Steps how to reproduce with parallel Dev-installation of  "Version 4.1.0.0.alpha0+ (Build ID: 61add5c77de1ff963b839020c77f67f14ef07de) TinderBox: Win-x86@6, Branch:master, Pull Time:  2013-03-05_00:20:08" ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with LODev/4 Masters User Profile:

1. Download and unzip  Attachment 76273 [details] for Bug 45286
2. Open "Target.ods"
3. Menu 'file -> Save as - Target.xlsx (MSO2007)
   > LibO becomes unresponding (sometimes responds after few minutes, sometimes
     not)

Same problem when save samd document as .xls, ok when save as .ods.
Not a general problem, works fine with document from other test kit in that bug.
Comment 1 Rainer Bielefeld Retired 2013-03-10 15:51:39 UTC
Already [Reproducible] with server installation of "LibO  4.0.1.2 release   -  German UI / German Locale  [Build ID: 84102822e3d61eb989ddd325abf1ac077904985)]"  {tinderbox: @6, pull time  2013-02-28 08:53(?)} on German WIN7 Home Premium (64bit) with newly created user profile ….\LibreOffice\4012\

Was still ok with 4.0.0.3
Comment 2 Terrence Enger 2013-03-11 01:32:26 UTC
I am confirming and setting platform ALL because I see the reported
slowdown with master commit 2082dc5, pulled around 2013-03-06 06:00
UTC, configured as
    --enable-dbgutil
    --enable-crashdump
    --disable-build-mozilla
    --without-system-postgresql
    --without-myspell-dicts
    --without-help
    --with-extra-buildid
built and running on ubuntu-natty (11.04) 32-bit.


Some observations, which my nasty suspicious mind finds suggestive:

(*) From the referenced Target.ods, I extracted content.xml, and
    passed the result through xml_pp, finding interesting values for
    rows-repeated.  In particular, 1048565 is one less than a number
    of iterations which will appear two bullet points below.  ...

        <table:table-row table:number-rows-repeated="1048565" table:style-name="ro1">
          <table:table-cell table:number-columns-repeated="1024"/>
        </table:table-row>
        ... 2 table-row's elided ...
      </table:table>
        
      <table:table table:name="Sheet2" table:style-name="ta2">
        ... 2 table-column's elided ...
        <table:table-row table:number-rows-repeated="1048575" table:style-name="ro1">
          <table:table-cell table:number-columns-repeated="1024"/>
        </table:table-row>
        ... 1 table-row elided ...
      </table:table>
      <table:table table:name="Sheet3" table:style-name="ta3">
        ... 2 table-column's elided ...
        <table:table-row table:number-rows-repeated="1048575" table:style-name="ro1">
          <table:table-cell table:number-columns-repeated="1024"/>
        </table:table-row>

(*) gdb `watch` on mnXclRowRpt in the fourth XclExpRow instantiated in
    the program shows the variable being initialized to 1 in the
    constructor and assigned value 1048566 in XclExpRow::SetXclRowRpt
    called from XclExpRowBuffer::Finalize ...

        2055:     sal_uInt32 nRpt =  rRow->GetXclRow() - pPrev->GetXclRow();
        2056:     pPrev->SetXclRowRpt( nRpt );

(*) XclExpRow::SaveXml uses mnXclRowRpt as the number of
    iterations for a loop which executes at least osl_writeFile.  The
    particular call to osl_writeFile which I happened to catch was
    writing 91 bytes.

(*) If I force an early return from XclExpRow::SaveXml for the
    object with a large mnXclRowRpt, the "Save As" appears to finish
    normally and the program displays the spreadsheet window.

HTH,
Terry.
Comment 3 Commit Notification 2013-03-12 13:52:27 UTC
Noel Power committed a patch related to this issue.
It has been pushed to "master":

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

fix for fdo#62111 - don't count non-default empty rows as rows to repeat



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.
Comment 4 Noel Power 2013-03-12 13:54:21 UTC
changed the title to reflect reality, no crash here, just a really long long export
Comment 5 Commit Notification 2013-03-12 14:47:49 UTC
Noel Power committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d2a17be89e98c6a7d8c172832c9491ce6c50506&h=libreoffice-4-0

fix for fdo#62111 - don't count non-default empty rows as rows to repeat


It will be available in LibreOffice 4.0.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.
Comment 6 Commit Notification 2013-03-18 13:58:45 UTC
Noel Power committed a patch related to this issue.
It has been pushed to "libreoffice-4-0-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=df77710e8137b2e4ddb60b4ca6919fd37ebe9654&h=libreoffice-4-0-2

fix for fdo#62111 - don't count non-default empty rows as rows to repeat


It will be available already in LibreOffice 4.0.2.

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.
Comment 7 Michael Stahl (allotropia) 2013-10-04 20:07:19 UTC
*** Bug 62430 has been marked as a duplicate of this bug. ***