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
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.
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 220.127.116.11 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 18.104.22.168 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?
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.
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Does the crash reporter catch them? Sometimes it doesn't, unfortunately..
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.
How much memory does your computer have?
The workstation I worked on is equipped with 32 GB of RAM and a Core i7-6820HQ processor.
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
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
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
(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?
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: 22.214.171.124.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
(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.
(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?
(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.
(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_126.96.36.199.beta1_Win_x64.msi
(In reply to Buovjaga from comment #12)
Well, that's still a developer version, a beta one.
(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
It turns out that the TOC links work. I just forgot to refresh the TOC before exporting to PDF.
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
(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 v188.8.131.52 long before v5.4 came out. That's the version that crashed.
(In reply to Daniel Grigoras from comment #17)
As I see that the version I had entered when I filed this ticket is 184.108.40.206, I tested v220.127.116.11. There was no crash loading and browsing the 4500 pages, but LibreOffice returned a bad allocation error during the export to PDF.
(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 18.104.22.168,
> I tested v22.214.171.124. 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.
(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
(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.