Closed Bug 914445 Opened 11 years ago Closed 10 years ago

"Assertion failure: mDeprecatedTextureClient (Failed to create texture client)"

Categories

(Core :: Graphics: Layers, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: assertion, testcase)

Attachments

(3 files)

Attached file testcase
With:
  user_pref("layers.use-deprecated-textures", true);

Assertion failure: mDeprecatedTextureClient (Failed to create texture client), at ../../../gfx/layers/client/CanvasClient.cpp:144
Attached file stack
Nical, thoughts?
Flags: needinfo?(nical.bugzilla)
{width = 21663, height = 27972}

First thought: That's a very big texture.
I wouldn't be surprised we just failed to allocate it. We need to pay attention to those assertions following allocation calls and make sure we provide with a fallback code path that maybe doesn't display the layer, but at least doesn't crash the browser.

I will give a closer look tomorrow.
Flags: needinfo?(nical.bugzilla)
needinfo'ing me again otherwise i'll forget
Flags: needinfo?(nical.bugzilla)
Now that you mention it - isn't CreateDeprecatedTextureClient(TEXTURE_FALLBACK) always going to return nullptr on OS X, so this assert will always trigger on anything but windows.
This doesn't actually fix the crash for me, but it does allow for the Create... returning nullptr.
(In reply to Milan Sreckovic [:milan] from comment #6)
> Created attachment 802479 [details] [diff] [review]
> WIP - doesn't fix the problem
> 
> This doesn't actually fix the crash for me, but it does allow for the
> Create... returning nullptr.

As in - it crashes elsewhere now.
How much priority does this bug have? I don't think it is very hard to fix. Basically we need to go through all the places where we allocate or request memory, and make sure we have a fallback path where either we pick a different allocation strategy or we just return without rendering the element that is too big to be allocated (always better than crashing).

With all the B2G craze these days I don't know if I should work on this now.
(In reply to Nicolas Silva [:nical] from comment #8)
> How much priority does this bug have? I don't think it is very hard to fix.
> Basically we need to go through all the places where we allocate or request
> memory, and make sure we have a fallback path where either we pick a
> different allocation strategy or we just return without rendering the
> element that is too big to be allocated (always better than crashing).
> 
> With all the B2G craze these days I don't know if I should work on this now.

Should be even easier than that - you probably just need to return a shmem or memory image texture client from CreateDeprecatedTextureClient for the TEXTURE_FALLBACK case.
Flags: needinfo?(nical.bugzilla)
No more deprecated textures, this seems to work fine.  Jesse, please reopen if you see it, but that pref is now obsolete and doesn't do anything.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: