Closed Bug 1155252 Opened 9 years ago Closed 5 years ago

Fix frequent linux64 debug crashes in 789933-1.html and re-enable the test

Categories

(Core :: Graphics, defect, P3)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: RyanVM, Assigned: nical)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(2 files)

Bug 994541 was hitting frequent crashes in 789933-1.html on linux64 debug. The test was temporarily disabled to get the trees green. This bug tracks finding the root cause so it can be re-enabled.
Huge canvases like the one in the failing test will fall back to BufferTextureClient. This should fix the crash.

I'll push it to try when try reopens.
Attachment #8593956 - Flags: review?(jmuizelaar)
Attachment #8593956 - Flags: review?(jmuizelaar) → review+
Sadly, the patch doesn't solve the X11 OOM issue https://treeherder.mozilla.org/#/jobs?repo=try&revision=a202d82e13d3

We should take it anyway because it limits the risks. I landed the fix without re-enabling the test.
Keywords: leave-open
(In reply to Nicolas Silva [:nical] from comment #4)
> We should take it anyway because it limits the risks. I landed the fix
> without re-enabling the test.

Except that you did re-enabled the test.
https://hg.mozilla.org/integration/mozilla-inbound/rev/38a2444bf818
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #5)
> (In reply to Nicolas Silva [:nical] from comment #4)
> > We should take it anyway because it limits the risks. I landed the fix
> > without re-enabling the test.
> 
> Except that you did re-enabled the test.
> https://hg.mozilla.org/integration/mozilla-inbound/rev/38a2444bf818

Gosh, indeed. Thanks!
I haven't managed to reproduce the crash locally, but if I have 5 instances running this test in a loop, the x server ends up getting killed by the low memory killer. So there is still something that tries to allocate large xlib surfaces.
We are also attempting to create an xlib surface with the (crazy) size of the canvas with X11DataTextureSourceBasic on the compositor side. if we put a limit there and just don't render the canvas, then we'll have allocated a huge TextureClient for nothing, so if we decide to do this we might as well also not create the TextureClient and not waste memory. We could also turn X11DataTextureSourceBasic into a BigImageIterator, and break the huge allocation in smaller ones, which would not reduce the memory consumption but at least avoid the huge allocation.

At the moment a page that contains a few huge canvases can cause the x server to get taken down by the low memory killer (bringing down firefox with all of the other open applications), so my preferred solution would be to just fail to create unreasonably large canvases and not attempt to composite them.
Attachment #8595450 - Flags: review?(jmuizelaar) → review+
Unlikely that I'll be working on this on the foreseeable future. This bug is a bit tricky to "finish" in the sense that this test as-is will always be intermittent (unless run on a machine with lots of RAM) We should not crash, now but we can't guarantee we'll be able to display super large canvases. It should probably be a crash-test instead.
Assignee: nical.bugzilla → nobody
Whiteboard: [gfx-noted]
The leave-open keyword is there and there is no activity for 6 months.
:davidb, maybe it's time to close this bug?
Flags: needinfo?(dbolter)
Assignee: nobody → nical.bugzilla
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(dbolter)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: