924215 - WebGL Conformance Test "crashes" Browser

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Layers, defect, P1)

Description

[Mandyam Vikram]

While trying to run the WebGL Conformance tests at:

https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/webgl-conformance-tests.html

the browser eventually "crashes" before the tests can finish. The error:
"Well, this is embarassing. We tried to display this web page, but,it's not responding".

I'm also attaching a logcat log which shows some additional WEbGL related failures as well.

Tested on v1.2 on a QRD 7x27 device with the following versions:
Gaia version: 
a13c76f8d3c617ee57c302c103da04ed1a6298d1
Gecko version:
85ead3614a3de104ca8b52c63a5b9b35c68feaa5

Comment 1

[Mandyam Vikram]

Attachment: crash.txt

Comment 2

[Kelsey Gilbert [:jgilbert]]

This appears to be a layers issue, given that the error appears to be hit in IPC send/recv.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Nical, can you take a look at this blocker?

Comment 4

[Mandyam Vikram]

Any news on this?

Comment 5

[Nicolas Silva [:nical]]

(In reply to Jeff Gilbert [:jgilbert] from comment #2)
> This appears to be a layers issue, given that the error appears to be hit in
> IPC send/recv.

The message ###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv
shows up when the communication channel is broken, independently of whether the app crashed in layers code.

I reproduced the bug and it turns out the app is sigkilled because the phone is running out of memory

Comment 6

[Nicolas Silva [:nical]]

(In reply to Nicolas Silva [:nical] from comment #5)
> I reproduced the bug and it turns out the app is sigkilled because the phone
> is running out of memory

Err actually I may have spoken too fast. It could be something in my patch queue that was causing this, not sure yet

Comment 7

[Nicolas Silva [:nical]]

Reproduced again with an empty patch queue and the tab still appears to be sigkilled because of OOM.
Is there any (even rough) regression range for this bug?

Comment 8

[Nicolas Silva [:nical]]

I managed to reduce the test case a bit: at least conformance/oes-standard-derivatives.html is crashing the browser with 100% repro for me so far.

reduced test case here:
http://people.mozilla.org/~nsilva/webgl/webgl-conformance-tests.html

Comment 9

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

The test URL here is the official Khronos WebGL conformance tests. We don't control this URL.

This test suite allocates fairly large WebGL textures and buffers. That's largely intentional. There is some room for debate there, but in any case the test URL here is the 1.0.1 version, and that is set in stone.

Now, the crash reported here, as pointed out above by Nicolas, is an out-of-memory kill. There is nothing that we can do to prevent that from happening while running heavy payloads in the browser, and the present conformance tests URL is such a heavy payload.

So this bug is probably not actionable. I also don't suppose that this ever ran on B2G v1.1, so this isn't a regression.

So I don't think that this is a blocker.

It seems that the reason why this was assigned to Nicolas is:

(In reply to Jeff Gilbert [:jgilbert] from comment #2)
> This appears to be a layers issue, given that the error appears to be hit in
> IPC send/recv.

The IPC send/recv is something that happens unconditionally in the B2G main process when some child process died and it's still trying to talk to it. It also is common to have a lot of layers-ipc-related stuff in logcat, just because layers-ipc is something that happens all the time. Nothing here points to a layers bug.

Comment 10

[Kelsey Gilbert [:jgilbert]]

Revive as needed.