Bug 104034 - specific EMF graphic crashing with OpenGL rendering enabled -- Crash in: basegfx::B2DPolygon::getB2DPoint(unsigned lon)
Summary: specific EMF graphic crashing with OpenGL rendering enabled -- Crash in: base...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.2.3.3 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0 target:5.2.5 target:5.3.0.1
Keywords: bibisected, bisected, regression
: 104462 (view as bug list)
Depends on:
Blocks: VCL-OpenGL EMF-WMF
  Show dependency treegraph
 
Reported: 2016-11-19 17:03 UTC by V Stuart Foote
Modified: 2016-12-13 11:58 UTC (History)
8 users (show)

See Also:
Crash report or crash signature: ["basegfx::B2DPolygon::getB2DPoint(unsigned long)"]


Attachments
EMF heraldic shield from slide in PowerPoint slide attachment 101574 (39.76 KB, image/x-emf)
2016-11-19 17:03 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2016-11-19 17:03:39 UTC
Created attachment 128875 [details]
EMF heraldic shield from slide in PowerPoint slide attachment 101574 [details]

With OpenGL rendering enabled the attached EMF file extracted from attachment 101574 [details] (12.5. Kariérní model - příklady.ppt from bug 80389) crashes LibreOffice on opening with both 5.2.3.3 build and the new HarfBuzz based layout engine of current master.

The EMF renders well with other viewers and can be opened and exported with LibreOffice default GDI rendering on both 5.2.3.3 and new HarfBuzz based layout in master.

On Windows 10 Pro 64-bit (1607) en-US with display/GPU

Name	NVIDIA GeForce GTX 750 Ti
PNP Device ID	PCI\VEN_10DE&DEV_1380&SUBSYS_37553842&REV_A2\4&1D0A902F&0&0018
Adapter Type	GeForce GTX 750 Ti, NVIDIA compatible
Adapter Description	NVIDIA GeForce GTX 750 Ti
Adapter RAM	(2,147,483,648) bytes
Installed Drivers	C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_d3851cb7c8216f9e\nvd3dumx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_d3851cb7c8216f9e\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_d3851cb7c8216f9e\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_d3851cb7c8216f9e\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_d3851cb7c8216f9e\nvd3dum,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_d3851cb7c8216f9e\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_d3851cb7c8216f9e\nvwgf2um,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_d3851cb7c8216f9e\nvwgf2um
Driver Version	21.21.13.7270

On Version: 5.2.3.3 (x64)
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US); Calc: group

This bug was filed from the crash reporting server and is br-782501d7-c185-40b1-a387-1d95f6ad670a.
=========================================

http://crashreport.libreoffice.org/stats/crash_details/42a46c99-5cab-46b2-91c4-0f7629ef59ed

http://crashreport.libreoffice.org/stats/crash_details/8320590a-14b5-452e-98b2-5400a343349f

http://crashreport.libreoffice.org/stats/crash_details/be42910a-a439-487c-ad2e-40345c6c37e2

and also for 5.3.0alpha1+
Version: 5.3.0.0.alpha1+ (x64)
Build ID: 9745d29227e471ce40e9992fefd92e10a48696fb
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-11-18_21:55:13
Locale: en-US (en_US); Calc: CL

http://crashreport.libreoffice.org/stats/crash_details/88d26ade-c341-4f68-9dab-53c03e31f8fc
Comment 1 Aron Budea 2016-11-21 11:31:11 UTC
Interestingly, my crash in 5.2.3.3 (x86) / Windows 7 is somewhat different.
It also gave a SEH Exception dialog when it crashed.

http://crashreport.libreoffice.org/stats/crash_details/868e51d8-a3c8-48a6-9a8d-f50a4812744d

No crash in 5.2.0.4 or 5.1.0.3 => regression. (Writer becomes sluggish after inserting the image, though)
Comment 2 V Stuart Foote 2016-11-21 12:55:58 UTC
(In reply to Aron Budea from comment #1)
> Interestingly, my crash in 5.2.3.3 (x86) / Windows 7 is somewhat different.
> It also gave a SEH Exception dialog when it crashed.
> 
> http://crashreport.libreoffice.org/stats/crash_details/868e51d8-a3c8-48a6-
> 9a8d-f50a4812744d

Looks like you are on an AMD Radeon GPU, and on Windows 7--so not too surprising to have slight differences. Hope one of our OpenGL smart devs can sort this out. Quite a number of crash reports piling up at the same spot. 

> 
> No crash in 5.2.0.4 or 5.1.0.3 => regression. (Writer becomes sluggish after
> inserting the image, though)

I didn't check the earlier builds.
Comment 3 Tor Lillqvist 2016-11-21 13:05:52 UTC
(Off-topic, sorry: That is one sad misuse of a vector format... It apparently encodes pixel rendering artefacts as vectors? Or is the image actually a pixel-based one anyway inside the EMF?)
Comment 4 Aron Budea 2016-12-07 12:25:23 UTC
*** Bug 104462 has been marked as a duplicate of this bug. ***
Comment 5 V Stuart Foote 2016-12-07 14:54:36 UTC
Opening test EMF document (attachment 128875 [details]) with OpenGL rendering, the 5.3.0beta1 build aborts at another spot in basegfx -- with default rendering, the EMF renders cleanly as vector.

http://crashreport.libreoffice.org/stats/signature/RenderList::addDrawPolyPolygon(basegfx::B2DPolyPolygon%20const%20&,double,unsigned%20long,unsigned%20long,bool)

http://crashreport.libreoffice.org/stats/crash_details/35f24f81-bdb8-424f-9b45-31c93d418ce6

http://crashreport.libreoffice.org/stats/crash_details/651d197b-6430-4190-9994-fa5c738130f1


=-=-=
On Windows 10 Pro 64-bit (1607) en-US with nVidia GTX-750ti (372.70)
Version: 5.3.0.0.beta1 (x64)
Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: CL
Comment 6 Aron Budea 2016-12-07 16:24:03 UTC Comment hidden (bibisection)
Comment 7 Aron Budea 2016-12-07 16:25:05 UTC
Adding Cc: to Tomaž Vajngerl, please take a look.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=aeb0c407a620ea8c28903f61d9d53e6d9ae7c53a
author	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2016-07-27 19:06:04 (GMT)
committer	Tomaž Vajngerl <quikee@gmail.com>	2016-07-28 13:05:06 (GMT)

"tdf#100915 draw antialiased line just for polygon outline
To get the anti-aliased polygon we draw a anti-aliased line around
every trapezoid. This works fine until we draw a transparent
polygon where the lines become visible because of blending. A much
better and faster way is to just draw the polygon outline with
anti-aliased lines. This is done with this commit."
Comment 8 V Stuart Foote 2016-12-07 18:11:25 UTC
(In reply to Aron Budea from comment #7)
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=aeb0c407a620ea8c28903f61d9d53e6d9ae7c53a

That may be it, because if I uncheck the Tools -> Options -> View: Use anti-alaising value but keep OpenGL opening the sample EMF does not crash.

But the graphic rendering with OpenGL is not at all smooth and looks rasterized.
Comment 9 Michael Meeks 2016-12-08 12:01:31 UTC
Aron's crash report is beautiful:

0	mergedlo.dll	basegfx::B2DPolygon::getB2DPoint(unsigned long)	basegfx/source/polygon/b2dpolygon.cxx:1157
1	mergedlo.dll	OpenGLSalGraphicsImpl::DrawPolyLine(basegfx::B2DPolygon const &,float,basegfx::B2DLineJoin,com::sun::star::drawing::LineCap,float)	vcl/opengl/gdiimpl.cxx:818

And line 818 is:

         glm::vec2 p1(rPolygon.getB2DPoint(nPoints - 1).getX(), rPolygon.getB2DPoint(nPoints - 1).getY());

I guess that we somehow have a single point line that has entered this code-path (?) =) and that nPoints-1 -> a very large unsigned number & bang ...

Aron - can you confirm that in the debugger ? I wonder what we should/could do in this case =)
Comment 10 Tomaz Vajngerl 2016-12-08 13:56:26 UTC
We just have to guard against such nonsense, I guess it is naive to expect that the EMF input filter takes care of this..
Comment 11 Tomaz Vajngerl 2016-12-08 14:03:09 UTC
Also, it is interesting that some of crashreports have "UseOpenGL = false". It seems that we can't rely on that being correct, but I don't know how it is possible.
Comment 12 Aron Budea 2016-12-08 14:19:20 UTC
(In reply to Tomaz Vajngerl from comment #11)
> Also, it is interesting that some of crashreports have "UseOpenGL = false".
> It seems that we can't rely on that being correct, but I don't know how it
> is possible.

Just tested this again, with the same result. OpenGL was definitely on at first (there's no crash if it's off), I got:
a crash, a "SEH Exception: ACCESS VIOLATION" dialog, then during the next start a crash report and a recovery dialog, and indeed by that time OpenGL rendering had been turned off automatically (and that state goes in the crash report).

A fresh crash report (it's the same as my previous one):
http://crashreport.libreoffice.org/stats/crash_details/45481103-70c8-4421-986c-d35d57621cbf
Comment 13 Aron Budea 2016-12-08 16:20:29 UTC
(In reply to Michael Meeks from comment #9)
> Aron - can you confirm that in the debugger ? I wonder what we should/could
> do in this case =)

Yes, I debugged in master in the place where Stuart's crash report pointed to in comment 5 (the code changed in 5.3), and indeed nPoints is 0 (it's the divisor of a modulo operation there).
Comment 14 Commit Notification 2016-12-08 17:22:21 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cee552d2071601b6f4131eda9e9a0a17768ea272

tdf#104034 skip polygons with less than 2 points

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 15 V Stuart Foote 2016-12-09 03:39:47 UTC
Drawing now with OpenGL enabled anti-alaised, on Windows 10 Pro 64-bit (1607) en-US with

Version: 5.4.0.0.alpha0+
Build ID: cb598029835477326b190bc99abd31a487cc5a91
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-12-09_00:51:51
Locale: en-US (en_US); Calc: CL
Comment 16 Tomaz Vajngerl 2016-12-09 11:48:51 UTC
Backport to libreoffice-5-3: https://gerrit.libreoffice.org/#/c/31789/

For libreoffice-5-2 the solution is different: https://gerrit.libreoffice.org/#/c/31790/
Comment 17 Commit Notification 2016-12-09 15:29:24 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=210d0999a2b997566f3aeb183f50b2aa2788dbf3&h=libreoffice-5-2

tdf#104034 skip polygons with less than 2 points (LO 5-2)

It will be available in 5.2.5.

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 18 Commit Notification 2016-12-13 11:58:44 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6cf3040fe180ae684a60655685a493843c2b162a&h=libreoffice-5-3

tdf#104034 skip polygons with less than 2 points

It will be available in 5.3.0.1.

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.