Created attachment 126770 [details] August.docx taken from bug 84678 LibreOffice exits with a crash when going to print preview immediately without first scrolling through this document. Steps to reproduce: -open example document, but don't move past page 2. -press the print preview icon. LO will crash tested with Ubuntu 16.04 x64 bibisect lo-daily-52 first bad commit: [4c8042c3e6e94228cf74f34711e4447356f0f63a] 2016-02-27: source-hash-af57a81d0c28944b424649f024c28f444a1ab2d9 bisect request because I can't guess at which commit that day caused the regression.
Hi Justin, cannot confirm with Version: 5.3.0.0.alpha0+ Build ID: a5a8006c4b77ea7fce4e6c808031c785373624eb CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-08-08_05:05:21 Locale: nl-NL (nl_NL.UTF-8); Calc: group
Hello Justin, *, I cannot confirm it on OS: Debian Testing AMD64 LO: Version: 5.2.0.4 Build-ID: 066b007f5ebcc236395c7d282ba488bca6720265 CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; Gebietsschema: de-DE (de_DE.UTF-8) nor Version: 5.2.1.1 Build-ID: 2d75cf29e6d05e44c404f0547047f1da6563d380 CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group ... :( Have you tested it with a newer version than 5.2.0.alpha1? Does your crash appear there, too? And which distribution / architecture are you using? Have a nice afternoon Thomas.
(In reply to thackert from comment #2) > Have you tested it with a newer version than 5.2.0.alpha1? Does your > crash appear there, too? And which distribution / architecture are you using? OS: Ubuntu 16.04 x64 Version: 5.3.0.0.alpha0+ Build ID: 176111160ddfbe4b6b36b300062bab156d46b211 CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group Also notice that I also consistently get it running through lo-linux-dbgutil-daily bibisect, so it isn't related to my autogen settings.
No crash. I also tried with gtk3 backend just in case. Justin: could you get a backtrace of the crash with symbols? Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.4 Build ID: 5.2.0-1 CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: f2d09e621757fb5f394998afecba399b638f2428 CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on August 12th 2016
Changing to WorksForMe The lo-linux-daily-dbgutl is also affected by ASSERTs, so this isn't really a problem for production builds. Sorry for the noise. soffice.bin: /home/vmiklos/git/libreoffice/master/sw/source/core/access/accmap.cxx:1718: virtual SwAccessibleMap::~SwAccessibleMap(): Assertion `(!mpShapeMap || mpShapeMap->empty()) && "Object map should be empty after disposing the root frame"' failed.
An assertion failed is still supposed to mean something is wrong, so let's keep this open. I'd assume it only triggers with assistive technologies enabled.
Created attachment 129031 [details] GDB trace of the crash with 5.4 master I had to do a dbgutil build. I had to have Orca running. It crashed after exiting print preview (not upon entering). Orca crashed as well. Version: 5.4.0.0.alpha0+ Build ID: 368de904974b18dc5a8d237e046c0ed005f7c85d CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: fi-FI (fi_FI.UTF-8); Calc: group
This is the assert that fails now: assert(!(mpEvents || mpEventMap)); http://opengrok.libreoffice.org/xref/core/sw/source/core/access/accmap.cxx#1745 The assert was introduced in Michael Stahl's commit below by changing OSL_ENSUREs to asserts, but the condition was never correct. https://cgit.freedesktop.org/libreoffice/core/commit/?id=d0b09f41efe938e94a84e783c9ff5742edcbfba8 "sw: related: tdf#58624 convert to assert() in ~SwAccessibleMap() With the restored Dispose() calls from previous commit these don't trigger on every scrolled document now." A slightly guess-based patch is now in gerrit: https://gerrit.libreoffice.org/#/c/31250/ The assert originally reported, and given in comment 5 came from the same commit, but has since been reverted by the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=2934f6bcc75c781cdf9e614b9d7d8533eb680b3f "sw: partially revert commit d0b09f41efe938e94a84e783c9ff5742edcbfba8 These still trigger sometimes in JunitTest_toolkit_unoapi_1 and i haven't had time to track that down, so back to SAL_WARN for now..."
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=002c1f7223a0363f848d37062a0043d63255ad94 tdf#101464 fix SwAccessibleMap::mpEvents assertions switching PrintPreview It will be available in 5.4.0. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b346439637b7d03a3eb1d6e67dfb585b357567f4 tdf#101464 sw: if a drawing object is moved, notify SwAccessibleMap It will be available in 5.4.0. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae06f4be6bbdebc10a88c386064d548848e57f80 tdf#101464 tdf#91260 sw: a11y for partially off-page drawing object It will be available in 5.4.0. 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.
that was a fascinating bugdoc. now i can't reproduce any more a11y assertion failures with it.
Seem the fix for this is causing a regression with shapes at the bottom of the page not displaying. http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae06f4be6bbdebc10a88c386064d548848e57f80 tdf#101464 tdf#91260 sw: a11y for partially off-page drawing object For example attachment 81684 [details] is now missing it's footer shape on page 2.
(In reply to Luke from comment #13) > Seem the fix for this is causing a regression with shapes at the bottom of > the page not displaying. thanks for the hint, it's not caused by this commit but the previous one, fixed on master in commit: commit ae3ec0d53a22ae5d2b7fb244a6056d0627b71873 Author: Michael Stahl <mstahl@redhat.com> AuthorDate: Fri Dec 16 17:21:48 2016 +0100 tdf#91260 sw: fix nasty corner case of SdrGroupObject in header or footer. Some very special handling going on to paint these in VOCOfDrawVirtObj with a GetSwDrawVirtObj().GetOffset() added; they are falsely identified as invisible because their sub-objects have an anchor set but it is always on the first page so to properly check them we'd have to add the same GetOffset() thing but checking the top-level object should be sufficient. please tell me if you find other odd corner case broken by tdf#91260 fix.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bdd1a03b450f9f8a0ead46c38bec58f6879b2c5d tdf#101464 tdf#91260 tdf#104620 sw: fix null SwPageFrame crash It will be available in 5.4.0. 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.
Strange. I still have the bisect window up. And this was definitely the result: $ git bisect bad ae06f4be6bbdebc10a88c386064d548848e57f80 is the first bad commit commit ae06f4be6bbdebc10a88c386064d548848e57f80 Maybe I made a mistake. In any case, thanks for fixing it so quickly!