699033 - [ANGLE] Assertion `typeName' failed // Parser Crash [@ TType::TType]

Status: VERIFIED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Christian Holler (:decoder)]

Attachment: Test case for browser

This bug was filed from the Socorro interface and is 
report bp-611f2a52-3fc5-4d96-8f62-67a322111102 .
============================================================= 

The attached WebGL testcase asserts in Firefox Nightly Debug (tested with mesa llvmpipe software rendering):

firefox: /builds/slave/m-cen-lnx64-dbg/build/gfx/angle/src/compiler/Types.h:209: const TString& TType::getTypeName() const: Assertion `typeName' failed.

Running in a release build, the test crashes at TType::TType (see crash report).

The test might require MOZ_GL_DEBUG=1.

This is another parser crash but not a null-deref according to the crash report. Marking this s-s until triaged and rated. Let me know if I shall report this to ANGLE or if you do so.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

oh, this one is very different from the others (bug 698963, bug 620222, bug 699015) and might be more serious. Not a null deref.

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

No need for MOZ_GL_DEBUG to reproduce this.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

ANGLE security bug: http://code.google.com/p/angleproject/issues/detail?id=241

Comment 4

[Johnny Stenback (:jst)]

Benoit, any idea what the timeline for getting a fix here, either cherry picked from Angle or through a new drop?

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

I just upgraded ANGLE to r885 which includes deep changes in the ANGLE compiler.

I can't reproduce the crash anymore in today's Nightly on Linux x86_64. Can you still reproduce?

Comment 6

[Christian Holler (:decoder)]

I can still reproduce the crash using nightly on Linux x86_64 (build 2011-11-21): https://crash-stats.mozilla.com/report/index/bp-0548938d-5942-40fc-a1b6-572cf2111121

Comment 7

[Johnny Stenback (:jst)]

Benoit, looks like this still happens after the angle update. Can you investigate further? Thanks!

Comment 8

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Chistian can you check that this is still valid? I believe a new version of angle has landed again in since the last time this bug was touched.

Comment 9

[Christian Holler (:decoder)]

Still crashes on a recent nightly: bp-a0a9f4e4-63d7-4136-ae5e-5f4a42120110

Comment 10

[Johnny Stenback (:jst)]

Benoit, this was filed 4 months ago, we need to move forward here, either by fixing this problem, or something else if we can't fix this.

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

I just pinged the bug @ANGLE. It's not clear whether it's been looked into.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

If we want to fix this bug ourselves, we need a developer who knows how to debug a compiler that uses bison-generated code.

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

The crash I'm still able to reproduce is a null pointer deref:
https://crash-stats.mozilla.com/report/index/fe00b5ce-d353-441b-9176-ef0102120223

I can't reproduce anymore the non-null pointer deref from the original crash report.

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

In a debug build it's pretty what's happening:

#2  0x00007ffff7343d4d in __GI___assert_fail (
    assertion=0x7ffff5e697b4 "typeName", file=<optimized out>, line=211, 
    function=<optimized out>) at assert.c:81
#3  0x00007ffff54b693c in TType::getTypeName (this=0x7fffd0c00000)
    at /home/bjacob/mozilla-central/gfx/angle/src/compiler/Types.h:211

    const TString& getTypeName() const
    {
        assert(typeName);  // <-- line Types.h:211
        return *typeName;
    }

We could turn this into a clear non-security bug by making this assert stay in release builds.

Also, the shader source triggering this is:

"\ninvariant Vertex  , Tex    , notEqual    , tan        ;\n"

Comment 15

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: castrate angle bug 241 to guarantee it's a plain crash, nothing worse

Comment 16

[Benoit Jacob [:bjacob] (mostly away)]

Landed on central, so this is no longer a serious security bug on central, but still a crash bug.

http://hg.mozilla.org/mozilla-central/rev/69255fe4cb94

Comment 17

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 600176 [details] [diff] [review]
castrate angle bug 241 to guarantee it's a plain crash, nothing worse

[Approval Request Comment]
Regression caused by (bug #): probably ever since we enabled WebGL
User impact if declined: potential heap corruption (this patch turns it into a plain 'innocuous' crash by abort())
Testing completed (on m-c, etc.): just landed on m-c
Risk to taking this patch (and alternatives if risky): No risk, trivial 1-line patch
String changes made by this patch: none

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 600176 [details] [diff] [review]
castrate angle bug 241 to guarantee it's a plain crash, nothing worse

[Triage comment]
Looks good, low risk.  Please land this today (02/27/12) in time for tomorrow's go-to-build on beta5

Comment 19

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Transplanted comment 16 to mozilla-aurora and mozilla-beta:

hg transplant -s ../mozilla-central/ 69255fe4cb94

http://hg.mozilla.org/releases/mozilla-aurora/rev/fa54977e954e
http://hg.mozilla.org/releases/mozilla-beta/rev/42612e9b5e2c

Comment 20

[Daniel Veditz [:dveditz]]

Cloning bug to deal with the non-exploitable crash as a follow-up

Comment 21

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

-> Fixed since mitigation landed on mozilla-central, mozilla-beta and mozilla-aurora.

esr10 is affected, waiting on tracking + flag for approval to land on esr10.

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 600176 [details] [diff] [review]
castrate angle bug 241 to guarantee it's a plain crash, nothing worse

[Triage Comment]
Approving taking this for esr10, please land asap as go-to-build is coming up on Friday March 1. See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for details on ESR landing process.

Comment 23

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/releases/mozilla-esr10/rev/9b4aa9c5f05d

Comment 24

[u279076]

Verified fixed on Firefox 10.0.3esr

Comment 25

[u279076]

Verified fixed in Firefox 11.0b6 (tried both build1 and debug build -- did not crash with the attached testcase).

Comment 26

[Christian Holler (:decoder)]

Verified that the crash is now a null-pointer crash on Nightly.

Comment 27

[u279076]

Verified fixed on Firefox 12b4 and Aurora 13.0a2 2012-04-04