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

VERIFIED FIXED

Status

()

--
critical
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: decoder, Assigned: bjacob)

Tracking

(Blocks: 1 bug, {crash, testcase})

Trunk
x86_64
Linux
crash, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox8- wontfix, firefox9- wontfix, firefox10- wontfix, firefox11 verified, firefox12+ verified, firefox13 verified, firefox-esr1011+ verified, status1.9.2 unaffected)

Details

(Whiteboard: [sg:critical][qa!], crash signature)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Created attachment 571323 [details]
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.
oh, this one is very different from the others (bug 698963, bug 620222, bug 699015) and might be more serious. Not a null deref.
No need for MOZ_GL_DEBUG to reproduce this.
status-firefox10: --- → affected
status-firefox11: --- → affected
status-firefox8: --- → wontfix
status-firefox9: --- → affected
tracking-firefox10: --- → +
tracking-firefox11: --- → +
tracking-firefox8: --- → -
tracking-firefox9: --- → +
Benoit, any idea what the timeline for getting a fix here, either cherry picked from Angle or through a new drop?
Assignee: nobody → bjacob
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?
(Reporter)

Comment 6

7 years ago
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
Benoit, looks like this still happens after the angle update. Can you investigate further? Thanks!
status-firefox9: affected → wontfix
tracking-firefox9: + → ---
tracking-firefox9: --- → -
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.
(Reporter)

Comment 9

7 years ago
Still crashes on a recent nightly: bp-a0a9f4e4-63d7-4136-ae5e-5f4a42120110
status-firefox12: --- → affected
tracking-firefox12: --- → +
status1.9.2: --- → unaffected
status-firefox-esr10: --- → affected
status-firefox10: affected → wontfix
status-firefox13: --- → affected
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.
status-firefox11: affected → wontfix
tracking-firefox10: + → -
tracking-firefox11: + → -
I just pinged the bug @ANGLE. It's not clear whether it's been looked into.
If we want to fix this bug ourselves, we need a developer who knows how to debug a compiler that uses bison-generated code.
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.
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"
Created attachment 600176 [details] [diff] [review]
castrate angle bug 241 to guarantee it's a plain crash, nothing worse
Attachment #600176 - Flags: review?(jst)
Attachment #600176 - Flags: review?(jst) → review+
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 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
Attachment #600176 - Flags: approval-mozilla-beta?
Attachment #600176 - Flags: approval-mozilla-aurora?
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
Attachment #600176 - Flags: approval-mozilla-beta?
Attachment #600176 - Flags: approval-mozilla-beta+
Attachment #600176 - Flags: approval-mozilla-aurora?
Attachment #600176 - Flags: approval-mozilla-aurora+
status-firefox11: wontfix → affected
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
Cloning bug to deal with the non-exploitable crash as a follow-up
Blocks: 731046
-> 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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
status-firefox11: affected → fixed
status-firefox12: affected → fixed
status-firefox13: affected → fixed
Resolution: --- → FIXED
tracking-firefox-esr10: --- → 11+
tracking-firefox11: - → ---
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.
Attachment #600176 - Flags: approval-mozilla-esr10+
status-firefox-esr10: affected → fixed
Verified fixed on Firefox 10.0.3esr
status-firefox-esr10: fixed → verified
Whiteboard: [sg:critical] → [sg:critical][qa+]
Verified fixed in Firefox 11.0b6 (tried both build1 and debug build -- did not crash with the attached testcase).
status-firefox11: fixed → verified
(Reporter)

Comment 26

7 years ago
Verified that the crash is now a null-pointer crash on Nightly.
Status: RESOLVED → VERIFIED
Verified fixed on Firefox 12b4 and Aurora 13.0a2 2012-04-04
status-firefox12: fixed → verified
status-firefox13: fixed → verified
Whiteboard: [sg:critical][qa+] → [sg:critical][qa!]
Group: core-security
You need to log in before you can comment on or make changes to this bug.