Bug Hunting Session
Bug 101464 - Assertion "(!mpShapeMap || mpShapeMap->empty())" failed when doing a print preview
Summary: Assertion "(!mpShapeMap || mpShapeMap->empty())" failed when doing a print pr...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha1
Hardware: All Linux (All)
: medium major
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:5.4.0
Keywords: accessibility, bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2016-08-12 11:38 UTC by Justin L
Modified: 2017-05-18 18:39 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
August.docx taken from bug 84678 (358.03 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-08-12 11:38 UTC, Justin L
Details
GDB trace of the crash with 5.4 master (25.50 KB, text/plain)
2016-11-26 13:29 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2016-08-12 11:38:34 UTC
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.
Comment 1 Cor Nouws 2016-08-12 13:59:50 UTC
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
Comment 2 Thomas Hackert 2016-08-12 15:23:39 UTC
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.
Comment 3 Justin L 2016-08-12 15:34:23 UTC
(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.
Comment 4 Buovjaga 2016-08-12 19:33:55 UTC
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
Comment 5 Justin L 2016-08-13 04:47:14 UTC
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.
Comment 6 Aron Budea 2016-08-13 15:05:29 UTC
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.
Comment 7 Buovjaga 2016-11-26 13:29:30 UTC
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
Comment 8 Aron Budea 2016-11-26 21:51:15 UTC
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..."
Comment 9 Commit Notification 2016-12-01 22:33:47 UTC
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.
Comment 10 Commit Notification 2016-12-07 13:50:50 UTC
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.
Comment 11 Commit Notification 2016-12-07 13:52:27 UTC
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.
Comment 12 Michael Stahl (CIB) 2016-12-07 14:00:09 UTC
that was a fascinating bugdoc.

now i can't reproduce any more a11y assertion failures with it.
Comment 13 Luke 2016-12-16 09:37:36 UTC
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.
Comment 14 Michael Stahl (CIB) 2016-12-16 16:42:31 UTC
(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.
Comment 15 Commit Notification 2016-12-16 16:43:12 UTC
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.
Comment 16 Luke 2016-12-16 18:39:24 UTC
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!