Description: Crash when exporting a presentation to PDF with Export notes pages enabled for a second time (LibO6.1.0.0) Steps to Reproduce: 1. Open attachment 140266 [details] (bug 116124) 2. File -> Export as PDF 3. Default settings except that: Export notes pages & Export Only Notes page are checked (General tab, under General) 4. First export -> Successful 5. Second export -> Crash Actual Results: Crash Expected Results: No crash Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.1.0.0.alpha0+ Build ID: 96d551636e9179eb6874a5156b191ef3bff0a10c CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-02-26_23:44:46 Locale: nl-NL (nl_NL); Calc: CL not in Version: 6.0.0.0.alpha1+ Build ID: dae6ba564fcf20299b7a560aeb346efc84364d41 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-11-01_00:28:17 Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
I can't reproduce it in Version: 6.1.0.0.alpha0+ Build ID: e2cb154195fdc2ffccdb6f5e87cae8b29640b3eb CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Faster STR 1. Open attachment 140266 [details] (bug 116124) 2. View -> Slide Sorter 3. Master Slides pane in the sidebar 4. Select all slides & apply a different template -> Crash
No crash for me with either steps in: Version: 6.1.0.0.alpha0+ (x64) Build ID: 96d551636e9179eb6874a5156b191ef3bff0a10c CPU threads: 4; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-02-27_00:54:40 Locale: en-US (en_US); Calc: CL
I can not confirm Version: 6.1.0.0.alpha0+ Build ID: dc8d8cbf30ca3429236eca16b8f447ef5d4e61d3 CPU threads: 1; OS: Windows 10.0; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-02-28_00:00:19
Created attachment 140328 [details] BT Still crashing even after a profile reset Version: 6.1.0.0.alpha0+ Build ID: e108a31a8fee09c2fa4031e45e45ed73bbdb7c6f CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-03_23:36:02 Locale: nl-NL (nl_NL); Calc: CL
I can't reproduce it in Version: 6.0.0.0.alpha1+ Build ID: 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: x11; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
It could be related to the image handling rework, I suppose. And might be related to bug 116042.. So it might resolve itself anyway.. I set this to NEEDINFO for the time being, and will check again after two weeks or so
better to close as a dupe of bug 116042 then... *** This bug has been marked as a duplicate of bug 116042 ***
(In reply to Telesto from comment #2) > Faster STR > 1. Open attachment 140266 [details] (bug 116124) > 2. View -> Slide Sorter > 3. Master Slides pane in the sidebar > 4. Select all slides & apply a different template -> Crash No crash. Can you crash it in Safe mode? Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 22b1d4784d02070ae1933c59cf2c9bb5a5284773 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on March 10th 2018 Version: 6.1.0.0.alpha0+ (x64) Build ID: 77db2da61658906c354084b13a95f1102949fbd0 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-04_22:51:24 Locale: fi-FI (fi_FI); Calc: group
Still reproducible Version: 6.1.0.0.alpha0+ Build ID: 5a341e126709e3c9ef01680e116d5ce0d55d9f8c CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-10_23:12:15 Locale: nl-NL (nl_NL); Calc: group It's a little harder to reproduce .. but still possible 1. Open attachment 140266 [details] (bug 116124) 2. File -> Export as PDF 3. Default settings except that: Export notes pages & Export Only Notes page are checked (General tab, under General) 4. First export -> Successful 5. Second export -> Successful 6. Third export -> Crash
(In reply to Telesto from comment #10) > Still reproducible > Version: 6.1.0.0.alpha0+ > Build ID: 5a341e126709e3c9ef01680e116d5ce0d55d9f8c > CPU threads: 4; OS: Windows 6.3; UI render: default; > TinderBox: Win-x86@42, Branch:master, Time: 2018-03-10_23:12:15 > Locale: nl-NL (nl_NL); Calc: group > > It's a little harder to reproduce .. but still possible > > 1. Open attachment 140266 [details] (bug 116124) > 2. File -> Export as PDF > 3. Default settings except that: > Export notes pages & Export Only Notes page are checked (General tab, under > General) > 4. First export -> Successful > 5. Second export -> Successful > 6. Third export -> Crash Tried four times without crash. Version: 6.1.0.0.alpha0+ (x64) Build ID: 4647057a077824cd6782be82b2d13e06fa76704b CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-13_02:03:59 Locale: fi-FI (fi_FI); Calc: group
(In reply to Buovjaga from comment #11) Repro with Version: 6.1.0.0.alpha0+ Build ID: 5b87abe06da35ca3a11628674af23460349b439a CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-12_23:45:38 Locale: nl-NL (nl_NL); Calc: CL No repro with Version: 6.1.0.0.alpha0+ (x64) Build ID: 4647057a077824cd6782be82b2d13e06fa76704b CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-13_02:03:59 Locale: nl-NL (nl_NL); Calc: group So, it could be x86 only
(In reply to Telesto from comment #12) > So, it could be x86 only Yep, I think it is due to memory use going through the roof (well, did not reach 1GB, but grew all the time). Version: 6.1.0.0.alpha0+ Build ID: 5b87abe06da35ca3a11628674af23460349b439a CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-12_23:45:38 Locale: fi-FI (fi_FI); Calc: group
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I see this in Windows 7 with 7.2+. 32-bit 7.2+ (2 weeks old) Skia crashes on step 2. of Comment 2. Memory waa just 650 MB. 64-bit 7.2+ with Skia few days old used to crash already on fileopen. No crash for Gdi, much less memory usage. But no crash with today's 64-bit. I noticed that Comment 2 steps in 7.1 Skia use 1.4 GB of memory, while Gdi doesn't reach 1 GB.
The presentation contains several huge images, the largest of them being 11826x8548. And they total about 200M pixels, or 800MiB RAM if stored as 32bpp, and this is just the images. GDI presumably can store as 24bpp, saving some memory, which Skia cannot do, but this is still a case of using a lot of data on a system that cannot really handle it.