Summary: | Stability issues when working with masterdocuments | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Daniel Grigoras <dani3l.grigoras> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | ilmari.lauhakangas, jbfaure, thomas.lendo |
Priority: | medium | ||
Version: | 5.3.2.2 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 107805 |
Description
Daniel Grigoras
2017-05-09 09:55:44 UTC
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 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 (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: 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 (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_5.4.0.0.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 v5.4.0.1 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 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. (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. (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. |