939117 - WebGL2: Assertion failure: targetSlot (unknown query object's type) [@mozilla::WebGLQuery::IsActive]

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Christoph Diehl [:posidron]]

Attachment: testcase

Tested with https://hg.mozilla.org/integration/mozilla-inbound/rev/67f5d934127c

and the following preferences:

user_pref("webgl.enable-draft-extensions", true);
user_pref("webgl.enable-prototype-webgl2", true);

Comment 1

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

Christoph: please also CC :djg on new WebGL bugs.

Comment 2

[Christoph Diehl [:posidron]]

Attachment: callstack

Comment 3

[Christoph Diehl [:posidron]]

Produces a weird stack-buffer-overflow in an opt build.

Comment 4

[Christoph Diehl [:posidron]]

Attachment: callstack-opt-build

Comment 5

[Kelsey Gilbert [:jgilbert]]

Crashes from unsupported configs probably shouldn't be 'critical'.

Comment 6

[Matt Wobensmith [:mwobensmith][:matt:]]

Unsupported config - unlikely for users to encounter - sec-moderate.

Comment 7

[u480271]

Attachment: Don't reference NULL ptr.

If GetQueryTargetSlot returns NULL, don't dereference it.

Comment 8

[u480271]

Try run: https://tbpl.mozilla.org/?tree=Try&rev=ce719409368a

Comment 9

[u480271]

Changed to ASSIGNED to follow Milan's protocol.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/32e6863fc29b

Does this affect any other branches?

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/32e6863fc29b

Comment 12

[u480271]

I checked with :jgilbert.

"No, because people shouldn't be browsing with prototype things enabled."

Comment 13

[Daniel Veditz [:dveditz]]

(In reply to Jeff Gilbert [:jgilbert] from comment #5)
> Crashes from unsupported configs probably shouldn't be 'critical'.

That's a tricky thing. This isn't exactly an 'unsupported config', it's a pref'ed off feature that we fully intend to turn on at some point. If we call this "moderate" and then don't fix it due to higher priorities then we end up with a forgotten sec-critical in our product.

On the other hand calling it sec-critical does overstate the current risk to our users. IMHO the closest we can get to reality in such situations is to call it sec-critical or sec-high but then note in the release status flags that it's 'unaffected' or 'disabled' for the various releases. Not great, but better than losing bad security bugs.

In this case it's all good, the bug got fixed anyway. You might as well get credit for finding and fixing a bad bug before release.