1379111 - Assertion failure: isEmpty() (failing this assertion means this LinkedList's creator is buggy: it should have removed all this list's elements before the list's destruction), at LinkedList.h:455

Status: RESOLVED DUPLICATE of bug 1376399

(Core :: Graphics: CanvasWebGL, defect, P3)

Description

[Carsten Book [:Tomcat]]

Attachment: stack

found via bughunter and reproduced on latest trunk m-c tinderbox build on win7

Steps to reproduce:
-> Load http://floooh.github.io/oryol-samples/asmjs/Dragons.html
--> instandly after 5-10 seconds

* Refused to create WebGL2 context because of blacklist entry: FEATURE_FAILURE_UNKNOWN_DEVICE_VENDOR
JavaScript warning: http://floooh.github.io/oryol-samples/asmjs/Dragons.js, line 1: Error: WebGL warning: Disallowing antialiased backbuffers due to blacklisting.
Initializing context 0CD13000 surface 0E454180 on display 13AD1CE0
err: rx::VertexDataManager::reserveSpaceForAttrib(438):         ! Assert failed in rx::VertexDataManager::reserveSpaceForAttrib(438): !bufferD3D || ElementsInBuffer(attrib, static_cast<unsigned int>(bufferD3D->getSize())) >= static_cast<int>(totalCount)
Assertion failed: !bufferD3D || ElementsInBuffer(attrib, static_cast<unsigned int>(bufferD3D->getSize())) >= static_cast<int>(totalCount), file c:/builds/moz2_slave/m-cen-w32-d-000000000000000000/build/src/gfx/angle/src/libANGLE/renderer/d3d/VertexDataManager.cpp, line 438

Assertion failure: isEmpty() (failing this assertion means this LinkedList's creator is buggy: it should have removed all this list's elements before the list's destruction), at c:\builds\moz2_slave\m-cen-w32-d-000000000000000000\build\src\obj-firefox\dist\include\mozilla/LinkedList.h:455

Note: bughunter rated this as exploitable so marking s-s

Comment 1

[Carsten Book [:Tomcat]]

Kats: is this something for you because of the VertexDataManager.cpp things ?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Redirecting to milan to find somebody for this. I've never dealt with VertexDataManager before, it looks like ANGLE innards.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

The bug is in the page, likely the bad stride value, off by a factor of the size of GL_FLOAT, perhaps?  Either way, we end up with a 64k buffer for 2603 floats with stride 64, which doesn't fit.

Or it's the fact that we have divisor set to 1, but the primcount is 0?

The validation fails to detect the problem until it's too late.  In ValidateDrawAttribs, around https://dxr.mozilla.org/mozilla-central/source/gfx/angle/src/libANGLE/validationES.cpp#57 we don't correctly compute maxVertexElement:

                if (attrib.divisor > 0)
                {
                    maxVertexElement =
                        static_cast<GLint64>(primcount) / static_cast<GLint64>(attrib.divisor);
                }
                else
                {
                    maxVertexElement = static_cast<GLint64>(maxVertex);
                }

We want it to be set to maxVertex, and it gets set to zero (as primcount is zero), so we happily ignore the fact that the buffer is too small.

The spec seems to allow primcount of zero (error is thrown on < 0 values), but it isn't clear (to me) if it's meant to behave as a no-op, or equivalent to primcount equal to 1.  Obviously, ANGLE doesn't treat it as a no-op, 'cause we assert & crash trying to deal with it :)

We should be able to have a test for this.  I can take a look next week.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Milan Sreckovic [:milan] from comment #3)
> The bug is in the page...

Or completely not this - Jeff has a better story, an ANGLE bug, already fixed upstream.  Stable Chrome crashes on this as well, but I haven't tested non-release versions.

Comment 5

[Daniel Veditz [:dveditz]]

Can we get a link to the angle bug added to the "see also" here?

Comment 6

[Samuel Vargas [:svargas]]

Sure: Bug 1376399

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

Not what Dan was asking for - do we have the ANGLE security (or otherwise) bug that is associate with this fix?  It doesn't appear that there is one; this was the patch that dealt with the problem: https://chromium-review.googlesource.com/c/422964/ and it references a *meta* like bug https://bugs.chromium.org/p/angleproject/issues/detail?id=1523.  I'll put that above for completeness, but it doesn't really help us when it comes to matching the Chrome security bug.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

I think we will wait for an ANGLE update here.

Comment 9

[Wennie]

Hi Milan:

I have assigned these security bugs to you to reassign them to appropriate developers in your team to investigate and fix them.

Thanks!

Wennie

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

I think we took care of this.