STATUS_ACCESS_VIOLATION chrome crash when screensharing window in presenter mode

I installed the latest jitsi stable on an AWS c5x.large Ubuntu 20.04 instance. Did a standard install, with let’s encrypt certificate.

Everything is working fine, I can do a meeting with 3 or more participants in high resolution, screenshare, chat, anything . There are no error in the console log. The websockets are OK too, I opened all the port just to be sure.

But a strange crash happen when screensharing application window in presenter mode, like for example Excel. I’m using chrome 100 on windows 10. I can trigger the crash when I keep resizing very quickly the window of the application. The error from Chrome is SATUS_ACCESS_VIOLATION. I keep resizing, but when the crash happen the size of the window of the application is roughly the same size as the display in jitsi. I can trigger this crash on different PC. I can’t reproduce on though, only my server.

Unfortunately, there are no error in the developer tool console. I also can’t find any error in prosody, jicofo or JVB logs. And I analyzed the crash dump of chrome with windbg but couldn’t find anything interesting in the call stack, it’s just the code of Chrome dealing with exception.

Did anybody encounter this error ? Any suggestion on how I can investigate it ?

Out of curiosity, what Prosody version are you running?

When you are running an interpreted software like Jitsi-meet (Javascript is an interpreted language), and it crashes, it’s always a fault in the framework that is running the interpreted language, that is in this case, Chrome itself or a library it is using.
Try to repro on another operating system, if it crashes too it’s surely a Chrome problem. I can’t do it for you on Linux, the description of the steps to repro is not precise enough.

Prosody could be involved in this ?! :sweat_smile:

It’s the default version that got installed by jitsi on Ubuntu, so prosody 0.12.0 (and lua 5.3 + luarocks 2.4.2

And here is the details of my jitsi package:

Package: jitsi-meet
Architecture: all
Version: 2.0.7001-1
Priority: optional
Section: net
Maintainer: Jitsi Team <>
Installed-Size: 13
Pre-Depends: jitsi-videobridge2 (= 2.1-634-gff8609ad-1)
Depends: jicofo (= 1.0-862-1), jitsi-meet-web (= 1.0.5913-1), jitsi-meet-web-config (= 1.0.5913-1), jitsi-meet-prosody (= 1.0.5913-1)
Recommends: jitsi-meet-turnserver (= 1.0.5913-1) | apache2
Filename: stable/jitsi-meet_2.0.7001-1_all.deb
Size: 3344
SHA256: 3d5df067038a674ac9e7fd50e2f5843f0dc26a7f0ceb05bc3dcabccf59bd651b
SHA512: 83d403b2f5e1816dbfb90244890aab70ce60644e10108f923cd6fa25ace440a1aab4a5cfa8bfbac112b8d431ebd8d7c0134c787dbc662f83297694697529cfc5
Description: WebRTC JavaScript video conferences
 Jitsi Meet is a WebRTC JavaScript application that uses Jitsi
 Videobridge to provide high quality, scalable video conferences.
 It is a web interface to Jitsi Videobridge for audio and video
 forwarding and relaying.
Description-md5: 8dc9b154db1848d22dc4ba9d4b1876d1

Prosody 0.12 has been causing some problems in the current Stable. Downgrade to the last version of Prosody 0.11.

It might be better to downgrade to lua 5.2 as well

I downgraded to Prosody 11 and lua 5.2 but still get crash.
Also I tried on a linux with VirtualBox Ubuntu 20.4 + chrome but couldn’t reproduce it.

Sorry about that. What I do:

  1. have a meeting with 3 persons or more. Actually I can also reproduce the crash with just one person in the conference but it seems easier to trigger when JVB is involved
  2. Start screensharing a window application
  3. Click on the camera button to start presenter mode
  4. Keep resizing the window until it crash

Here is a demonstration

Yeah I cannot reproduce this on macosx. It sounds like a chrome bug on windows.
Does it happen only with presenter mode on? Or you reproduced it with just sharing a window?

It’s only with presenter mode and only with window sharing.

Because of that I suspected it may have something to do with the way the canvas in JitsiStreamPresenterEffect.js is dynamically resized every frame (the canvas onto which the desktop stream and the webcam stream are drawn).But I put some traces around the function _onVideoFrameTimer and when the crash happen it’s out of the function.

I see, the interesting part is that you cannot reproduce on That is ahead of the stable you are running, but maybe some of the commits are changing the behavior…

If it is easy for you to test with one of the latest unstable versions …

That’s a really good point, I’m going to try with unstable, thanks!

Edit : Does already use multi stream for screen sharing ? That would change quite a lot how the presenter mode work, I guess,

I have tried to destroy Chromium 100.0.4896.75 (Build officiel) snap (64 bits) under Ubuntu 18.04 by moving the mouse madly for 2 minutes without any crash.
It was with unstable and ‘classic’ screensharing.

gerard@q1900:~$ curl -s -k | grep sourceNameSignaling

IOW: no. It’s not enabled by default on unstable either.

Thanks for your dedication :grinning:

Meanwhile I switched to the latest Jitsi unstable ( with prosody 0.11), but still get a crash like in the video. Happen both on my home PC and work PC (both windows 10/chrome100) so I guess it’s not like a bad graphic card driver or something. And users in my organization also report crash when using presenter mode + window screensharing, I’m a bit at a loss to track from where the problem is coming from and why it doesn’t happen on…