Bug 107719 - Stability issues when working with masterdocuments
Summary: Stability issues when working with masterdocuments
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Master-Doc
  Show dependency treegraph
 
Reported: 2017-05-09 09:55 UTC by Daniel Grigoras
Modified: 2017-08-08 11:58 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 Daniel Grigoras 2017-05-09 09:55:44 UTC
Description:
It's impossible to work with masterdocuments on Windows 10, even if that means importing just a few subdocuments (3 in my case) with no more than a few hundred pages (250 to be precise), as LibreOffice crashes at some point while I scroll down the masterdocument and edit the contents of the subdocuments imported (tables, references, diagrams, styles, plain text).

As a general note, it's impossible for me to work with masterdocuments containing many subdocuments (92) and many pages (3600 pages) on both Linux and Windows, as LibreOffice either crashes (immediately on Windows 10), or, when it does load them (as I managed on Windows 7 starting with LibreOffice 5.3) it exported to PDF only 2600 pages out of 3600.

Steps to Reproduce:
1. Load 90+ subdocuments into a masterdocument, amounting to several thousand pages (filled with tables, diagrams, equations, cross-references, bookmarks, footnotes, etc.)
2. If LibreOffice does not crash while importing the subdocuments, then scroll down the masterdocument to edit the contents, as many issues may be found (such as badly layed out tables and figures, missing references) due to various non-LibreOffice related reasons, such as things that were missed by the technical writer at the subdocument level.
3. If LibreOffice does not crash during the editing of the contents imported from the subdocuments, try exporting to PDF

Actual Results:  
LibreOffice crashes during the import of the subdocuments or during the editing of the contents imported from the subdocuments or it fails to export a complete PDF version.

Don't ask for samples as I work with highly confidential proprietary information and it would be very difficult to create anonymized version.

Expected Results:
I would have expected to be able to work with masterdocuments and subdocuments in LibreOffice by now. Currently I only have managed to do this with LibreOffice 4.3.5.2 on Ubuntu 14 and the strange configuration reached on this particular environment after various installs and uninstalls, upgrades and downgrades. I could not replicate this environment even after I installed Ubuntu 14 and LibreOffice 4.3.5.2 on a different computer (though I admit that in a virtual machine). I'm afraid that if in the event of an unfortunate event something bad will happen with this strange OS environment or the partition it resides on I'll be unable to fulfill my most demanding job task, that of publishing a large 3600-page databook to PDF format. Should I still rely on fortune?


Reproducible: Always

User Profile Reset: Yeah, I know that sometimes I have to reset my user profile so that custom tables of contents are properly displayed, which is really lame. I remember trying this so-called solution when working with masterdocuments, but to no avail.

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Comment 1 Buovjaga 2017-05-12 17:27:32 UTC
Does the crash reporter catch them? Sometimes it doesn't, unfortunately..
Comment 2 Daniel Grigoras 2017-05-16 09:23:54 UTC
I tried again to load the subdocuments on Windows 10 and this time they were all safely loaded, however LibreOffice froze after a while because of the autosave feature. I disabled autosave and I was able to export to PDF, but while LibreOffice was about three quarters of the way to the exporting of the PDF it crashed returning a bad allocation error. No crash logs were saved.
Comment 3 Buovjaga 2017-05-16 09:51:11 UTC
How much memory does your computer have?
Comment 4 Daniel Grigoras 2017-05-16 10:10:45 UTC
The workstation I worked on is equipped with 32 GB of RAM and a Core i7-6820HQ processor.
Comment 5 Daniel Grigoras 2017-05-22 17:02:03 UTC
I have managed to anonymize the contents of the masterdocument and subdocuments I work with and which make LibreOffice crash and return a bad allocation error even when just loading the subdocuments in the masterdocument.

You can download them for testing purposes from here: https://www.dropbox.com/s/nsa8ym1kmxt3ltg/00_MASTERDOC.zip?dl=0
Comment 6 Buovjaga 2017-05-23 18:12:42 UTC
I opened the master and inserted all the provided subdocuments at once. I also have 32 GB of memory, i7 CPU and SSD, but it took a long time to finish import (so didn't crash).

The document was write protected, so I did not make changes.

I exported a PDF. It took a long time, but was successful.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.5.0.0.alpha0+
Build ID: 6b5fc059543c16759abd5eec2576b5b68e96883a
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on May 21st 2017
Comment 7 Daniel Grigoras 2017-05-24 06:29:43 UTC
(In reply to Buovjaga from comment #6)

I see that you worked with a version of LibreOffice that is not available for the general public, at least not on the LibreOffice website.
Moreover, you tested this on Linux, not Windows.
Furthermore, you did manage to load all of the subdocuments, but you have not tried to scroll down the document and edit it as on Windows LibreOffice usually crashed after several edits. In my experience some graphics jump pages and leave a lot of empty pages behind them. Also, the rows of some tables also jump pages making some tables split by empty pages. You can edit the content loaded by going to Format->Sections and there remove the write protection. 
Other than that, what is the page count of your PDF? Is it the same as the page count in the masterdocument?
Comment 8 Buovjaga 2017-05-24 17:24:22 UTC
The builds are available to the public: http://dev-builds.libreoffice.org/daily/master/

Thanks for the Format - Sections tip.

Now I tried with a Win 10 VM, which of course has less resources. I could open successfully and do several edits without crashing. PDF exported with 3880 pages, which was the same number displayed in LibO after the export.

Version: 5.5.0.0.alpha0+ (x64)
Build ID: 687c3b49976ef0eb079853f7bffd63d25bff05c7
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-05-24_01:23:43
Locale: fi-FI (fi_FI); Calc: group
Comment 9 Daniel Grigoras 2017-05-25 14:56:49 UTC
(In reply to Buovjaga from comment #8)

Indeed, with the 5.5 developer build I was successful in producing a PDF from the master document on Windows. That's wonderful.

However, I noticed that upon clicking on the table of contents links, those links don't work.
Comment 10 Buovjaga 2017-05-25 15:00:24 UTC
(In reply to Daniel Grigoras from comment #9)
> (In reply to Buovjaga from comment #8)
> 
> Indeed, with the 5.5 developer build I was successful in producing a PDF
> from the master document on Windows. That's wonderful.
> 
> However, I noticed that upon clicking on the table of contents links, those
> links don't work.

Ok, I think you should create a new report for the link bug. 

Are you ok to close this as worksforme?
Comment 11 Daniel Grigoras 2017-05-25 15:17:18 UTC
(In reply to Buovjaga from comment #10)

Honestly, I'd be ok to close this bug report if a non-developer build were available with this improvement.
Comment 12 Buovjaga 2017-05-25 15:24:55 UTC
(In reply to Daniel Grigoras from comment #11)
> (In reply to Buovjaga from comment #10)
> 
> Honestly, I'd be ok to close this bug report if a non-developer build were
> available with this improvement.

Well you can also test with 5.4 beta: http://dev-builds.libreoffice.org/pre-releases/win/x86_64/LibreOfficeDev_5.4.0.0.beta1_Win_x64.msi
Comment 13 Daniel Grigoras 2017-05-25 15:51:44 UTC
(In reply to Buovjaga from comment #12)

Well, that's still a developer version, a beta one.
Comment 14 Buovjaga 2017-05-25 15:55:38 UTC
(In reply to Daniel Grigoras from comment #13)
> (In reply to Buovjaga from comment #12)
> 
> Well, that's still a developer version, a beta one.

Yes, but it will be released as final in 2 months: https://wiki.documentfoundation.org/ReleasePlan/5.4
Comment 15 Daniel Grigoras 2017-05-25 17:05:09 UTC
It turns out that the TOC links work. I just forgot to refresh the TOC before exporting to PDF.
Comment 16 Jean-Baptiste Faure 2017-08-05 20:46:26 UTC
LibreOffice 5.4 is now out. Does it solve the problem for you?

Set status to NEEDINFO, please set it back to UNCONFIRMED once requested
informations are provided.

Best regards. JBF
Comment 17 Daniel Grigoras 2017-08-08 06:57:30 UTC
(In reply to Jean-Baptiste Faure from comment #16)
> LibreOffice 5.4 is now out. Does it solve the problem for you?
> 
> Set status to NEEDINFO, please set it back to UNCONFIRMED once requested
> informations are provided.
> 
> Best regards. JBF

Really? Well, I have been using v5.4.0.1 long before v5.4 came out. That's the version that crashed.
Comment 18 Daniel Grigoras 2017-08-08 07:50:27 UTC
(In reply to Daniel Grigoras from comment #17)


As I see that the version I had entered when I filed this ticket is 5.3.2.2, I tested v5.4.0.1. There was no crash loading and browsing the 4500 pages, but LibreOffice returned a bad allocation error during the export to PDF.
Comment 19 Buovjaga 2017-08-08 11:46:58 UTC
(In reply to Daniel Grigoras from comment #18)
> (In reply to Daniel Grigoras from comment #17)
> 
> 
> As I see that the version I had entered when I filed this ticket is 5.3.2.2,
> I tested v5.4.0.1. There was no crash loading and browsing the 4500 pages,
> but LibreOffice returned a bad allocation error during the export to PDF.

I discussed with developers and it turned out "Out of memory" situations are not something we want to handle. Crashing is the only sane solution.
Thus I will close this.
Comment 20 Daniel Grigoras 2017-08-08 11:52:39 UTC
(In reply to Buovjaga from comment #19)

> I discussed with developers and it turned out "Out of memory" situations are
> not something we want to handle. Crashing is the only sane solution.
> Thus I will close this.

I haven't received any bad allocation crash error when exporting to PDF LibreOfficeDev 6, so I don't understand what you meant by saying that you don't want to handle/fix an issue that seems to have been fixed in v6.0
Comment 21 Buovjaga 2017-08-08 11:58:59 UTC
(In reply to Daniel Grigoras from comment #20)
> (In reply to Buovjaga from comment #19)
> 
> > I discussed with developers and it turned out "Out of memory" situations are
> > not something we want to handle. Crashing is the only sane solution.
> > Thus I will close this.
> 
> I haven't received any bad allocation crash error when exporting to PDF
> LibreOfficeDev 6, so I don't understand what you meant by saying that you
> don't want to handle/fix an issue that seems to have been fixed in v6.0

Right, you said so in comment 9, I forgot.