WebGL context lost (libcef.dll crash)

Hi, the following crash was first reported to me yesterday in a 5 month old paid video call resource and I have been able to reproduce it in multiple clients.

The crash happens as soon a live MediaStreamTrack is played via WebRTC. Sometimes it takes a few tries before it occurs. Tested in latest Canary and Release channels.

After this crash occurs, anything WebGL related does no longer work and trying to create a WebGLRenderer throws “Error creating WebGL context” until a game restart. The game itself does not crash.

I understand this is a very specific use-case and if the following does not give you anything to work with I will be more than happy to try and create a minimal POC of the crash.

[    207688] [b2189_DumpServ]                39944/ Process crash captured. Crash dialog content:
[    207688] [b2189_DumpServ]                39944/ libcef.dll!mojo::Connector::RaiseError (0x0)
[    207688] [b2189_DumpServ]                39944/ An error at libcef.dll!mojo::Connector::RaiseError (0x0) caused FiveM to stop working. A crash report is being uploaded to the FiveM developers.
[    207688] [b2189_DumpServ]                39944/ Stack trace:
[    207688] [b2189_DumpServ]                39944/   libcef.dll!mojo::Connector::RaiseError (0x0) (connector.cc:226)
[    207688] [b2189_DumpServ]                39944/   libcef.dll!mojo::internal::MultiplexRouter::ProcessIncomingMessage (0x238) (multiplex_router.cc:954)
[    207688] [b2189_DumpServ]                39944/   libcef.dll!mojo::internal::MultiplexRouter::Accept (0xf7) (multiplex_router.cc:622)
[    207688] [b2189_DumpServ]                39944/   libcef.dll!mojo::MessageDispatcher::Accept (0xbb) (message_dispatcher.cc:43)
[    207688] [b2189_DumpServ]                39944/   libcef.dll!mojo::Connector::DispatchMessageW (0xfe) (connector.cc:509)
[    207688] [b2189_DumpServ]                39944/   libcef.dll!mojo::Connector::ReadAllAvailableMessages (0xf9) (connector.cc:568)
[    207688] [b2189_DumpServ]                39944/   libcef.dll!base::RepeatingCallback<void (unsigned int, const mojo::HandleSignalsState &)>::Run (0xc) (callback.h:169)
[    207688] [b2189_DumpServ]                39944/ 
[    210172] [b2189_DumpServ]                39944/ Crash report service returned si-d0fb2c9aecbc4da0b7b83389d8b7b18f
1 Like

Any… repro? Or perhaps the actual dump?

Okay, I am on it.

Yeah - it’s a bit hard to diagnose Chrome crashes without actually being able to cause them. :confused:

1 Like

Here’s the latest dmp from this. Working on a minimal repro now.

dbca087e-b04c-477c-80cd-5d95f19c0922.dmp (936.3 KB)

I have sent you a direct message with the repro.

I tried running it but it works fine for some reason. :confused:

Do you happen to have cef.log for a failure case, perhaps?

I have high reproducibility in two PCs, can give you cloud access to one if it would help. :thinking:

cef.log (7.5 KB)

[0505/232239.975:ERROR:validation_errors.cc(116)] Invalid message: VALIDATION_ERROR_DESERIALIZATION_FAILED
[0505/232239.975:ERROR:gpu_child_thread.cc(58)] Mojo error in GPU process: Validation failed for viz.mojom.CompositorFrameSink.2  [VALIDATION_ERROR_DESERIALIZATION_FAILED]

Indeed what I expected. Somehow it doesn’t seem to log what deserialization failed, though, which is why I was hoping for a working repro. :confused:

What GPU is it failing consistently with? This might be related to some different code path for different drivers or so.

Failing in both NVIDIA RTX 2080 Ti and NVIDIA 1660 Ti. The logs are from the first one. If of any help I can gather more GPU models that it fails with.

Just a heads up that I found a hotfix for my video call resource: using a buffer to the live MediaStreamTrack and then display it in a video does no longer make WebGL crash (in an expense of a second delay in the video feed which is something me and my customers can live with).

So if this is a big pain for you to figure out, since its a very specific use-case (I’d assume), it can be left alone. I’m still up to help in any way to get to the root of it however.