1341131 - Crash in rx::CopyNativeVertexData<T> in Zen Garden demo

Status: RESOLVED FIXED

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

Description

[Jukka Jylänki]

This bug was filed from the Socorro interface and is 
report bp-74c00195-152a-4d5d-af11-4ed972170220.
=============================================================

Comment 1

[Jukka Jylänki]

Another crash report: https://crash-stats.mozilla.com/report/index/0b7f8189-3eec-45ff-9d7a-0a89d2170220

Comment 2

[Jamie Nicol [:jnicol]]

Do we have steps to reproduce? (Is it a specific demo only?)

Comment 3

[Jukka Jylänki]

I have sent STR to Jeff Gilbert and Milan off band in email, currently waiting to hear from them.

Comment 4

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

I managed to get a crash clicking on the fish pond, but that was once, and I didn't get the proper crash report so I can't tell if it was this stack or not.  Workflow wise, other than "run the data", is there a sure way you can reproduce this?

Comment 5

[Michael Leu[:Lenzak](UTC+8)]

I can reproduce it, and the stack looks exactly the same.

It happens with very high frequency after I change my GFX card to GTX1070, not sure it is relevant, though.

Looks like the input data of glDrawElement is busted before copy for some reason.

Comment 6

[Michael Leu[:Lenzak](UTC+8)]

OK, there are 2 crash places here.

The one is in ANGLE which is mentioned in this bug, and the other seems to be in the WASM part.

Most of crash on my PC happens when the demo just startup, I think they are not this bug but a WASM failure.

So the ANGLE crash happens intermittently, I will do more test for it and I wonder whether glDrawElement will crash or not if we disable ANGLE.

Comment 7

[Jukka Jylänki]

Thanks a million in diagnosing this Michael, this is super critical help! Do you have a callstack for the Wasm part?

If you disable Wasm in about:config, does it avoid the crash altogether? (there is an asm.js fallback in the page)

CCing Luke for visibility on the Wasm side.

Comment 8

[Luke Wagner [:luke]]

The given crash stack is in the asm.js-caching path, so disabling *asm.js* (javascript.options.asmjs = false) is what you'd want to test.

Comment 9

[Michael Leu[:Lenzak](UTC+8)]

mozglue.dll!wrap_strdup(const char * src) Line 86	C
xul.dll!js::DuplicateString(const char * s) Line 3383	C++
xul.dll!JS::DescribeScriptedCaller(JSContext * cx, JS::AutoFilename * filename, unsigned int * lineno, unsigned int * column) Line 6750	C++
xul.dll!nsGlobalWindow::ShowSlowScriptDialog() Line 11502	C++
xul.dll!XPCJSContext::InterruptCallback(JSContext * cx) Line 1361	C++
xul.dll!InvokeInterruptCallback(JSContext * cx) Line 432	C++
xul.dll!WasmHandleExecutionInterrupt() Line 97	C++
000000fed0eecdc5()	Unknown
000000003f800000()	Unknown

This is stack dump by Visual Studio.

I ran the demo under nightly before bug1338002 landed because both demos didn't work anymore after it landed.

I will test newer UDK demo which is compatible to newer WASM validation mechanism.

Comment 10

[Benjamin Bouvier [:bbouvier] (inactive)]

(In reply to Michael Leu[:Lenzak](UTC+8) from comment #9)
> mozglue.dll!wrap_strdup(const char * src) Line 86	C
> xul.dll!js::DuplicateString(const char * s) Line 3383	C++
> xul.dll!JS::DescribeScriptedCaller(JSContext * cx, JS::AutoFilename *
> filename, unsigned int * lineno, unsigned int * column) Line 6750	C++
> xul.dll!nsGlobalWindow::ShowSlowScriptDialog() Line 11502	C++
> xul.dll!XPCJSContext::InterruptCallback(JSContext * cx) Line 1361	C++
> xul.dll!InvokeInterruptCallback(JSContext * cx) Line 432	C++
> xul.dll!WasmHandleExecutionInterrupt() Line 97	C++
> 000000fed0eecdc5()	Unknown
> 000000003f800000()	Unknown
> 
> This is stack dump by Visual Studio.
> 
> I ran the demo under nightly before bug1338002 landed because both demos
> didn't work anymore after it landed.
> 
> I will test newer UDK demo which is compatible to newer WASM validation
> mechanism.

This could be just bug 1341080 (considering the ShowSlowScriptDialog call in the stack trace), which landed after bug 1338002.

Comment 11

[Kelsey Gilbert [:jgilbert]]

Can you assign this, Peter?

Comment 12

[Michael Leu[:Lenzak](UTC+8)]

It seems to be an ANGLE crash, I'm now testing upgrading ANGLE to 2950 for bug863316, I will also try whether it will crash or not.

Comment 13

[Peter Chang[:pchang]]

Michael will check this with new ANGLE rev.

Comment 14

[Michael Leu[:Lenzak](UTC+8)]

I have upgraded ANGLE to 2950 and the crash still persists.

I will try disabling ANGLE to verify whether it is an ANGLE problem or not.

Comment 15

[Michael Leu[:Lenzak](UTC+8)]

OK, the crash doesn't happen if ANGLE is disabled, but using native GL exhibits some flickering and glitched frames when running the demo.

Comment 16

[Michael Leu[:Lenzak](UTC+8)]

I have tested Chrome with same demo site and they didn't crash, I think they have cherry-picked some cset in ANGLE trunk which fix this issue, I will try to find it.

Comment 17

[Andre Weissflog]

I'm also seeing a crash in rx::CopyNativeVertexData() in one of my new Oryol demos on Windows, ticket is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1376399

Comment 18

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is an assigned P1 bug without activity in two weeks. 

If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword.

Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.

Comment 19

[Jukka Jylänki]

This is still a P1 item, a GPU independent browser crash in the launch demo of David Bryant's WebAssembly post: https://medium.com/mozilla-tech/why-webassembly-is-a-game-changer-for-the-web-and-a-source-of-pride-for-mozilla-and-firefox-dda80e4c43cb

Please do not reset the priority of this item.

Comment 20

[Kelsey Gilbert [:jgilbert]]

Jukka: Does it still crash for you now that bug 1376399 is fixed?

Comment 21

[Jukka Jylänki]

Looks like this works perfectly now. Great work!