2012006 - Firefox 147 crashes more than 50% of the times with online meetings (Google Meet, Teams) on Fedora

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect)

Description

[André Costa]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

I started a Google Meet online meeting (it happens with MS Teams meetings as well). After leaving the meeting, I try to join a new one.

Actual results:

The first meeting happens mostly fine (although system load goes a little to high in my opinion -- 3.0+ on a AMD Radeon 890M which should be able to decode and encode some codecs). After I leave this meeting, the minute I try to join a new one, Firefox crashes. I ran it from the console and this is what it outputs to stderr:

Fatal error in: /builddir/build/BUILD/firefox-147.0.1-build/firefox-147.0.1/third_party/libwebrtc/modules/video_capture/linux/video_capture_pipewire.cc, line 148

last system error: 0

Check failed: format != SPA_VIDEO_FORMAT_UNKNOWN

Redirecting call to abort() to mozalloc_abort

ExceptionHandler::GenerateDump attempting to generate:/home/costa/.mozilla/firefox/4l8UOC6q.Profile 1/minidumps/2d6295d8-a3aa-c1b6-79ca-345d1c59876b.dmp
ExceptionHandler::GenerateDump cloned child 19483
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::GenerateDump minidump generation succeeded
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

This is 100% reproducible on my laptop (AMD Ryzen AI 9 365 running Fedora 43), and sometimes even the first meeting after restarting the browser crashes the browser. At least one time it seems some sort of zombie process seemed to have survived the crash, because the system load went beyond 6.0 when I joined a new meeting.

Expected results:

Leaving/entering meetings should not crash Firefox. Also, CPU usage seems too high on a high-end system with a capable iGPU

Comment 1

[André Costa]

(sorry for the ugly formatting, I forgot I was writing markdown and simply pasted the output)

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Please attach your about:support page and also any crash ID you have (you need to submit them first):
https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Using_Mozilla_crash_reporter
If that's Fedora it can be caused by GCC or pipewire or so.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Jan, any idea here?

Fatal error in: /builddir/build/BUILD/firefox-147.0.1-build/firefox-147.0.1/third_party/libwebrtc/modules/video_capture/linux/video_capture_pipewire.cc, line 148
last system error: 0
Check failed: format != SPA_VIDEO_FORMAT_UNKNOWN
Redirecting call to abort() to mozalloc_abort

Comment 5

[Jan Grulich]

Hi, can you please run Firefox with MOZ_LOG=webrtc_trace:5 and go to e.g. https://mozilla.github.io/webrtc-landing/gum_test.html to try to reproduce the issue? Or does it happen only with Google Meet? Can you please attach the output here after you reproduce the issue?

This looks like somehow a video format is announced, that we don't support, but it somehow still slips through and results into hitting the assert.

Comment 6

[André Costa]

Thanks Martin and Jan. Here's the info you requested:

Crash report ID and date

bp-2bbc0da7-94fa-4794-8847-554e90260122 	1/22/26, 17:09
bp-23544524-52e4-4949-9800-ae0d70260122 	1/22/26, 15:03
bp-35d7b117-da49-4724-8cbe-91e0c0260122 	1/22/26, 14:00
bp-b9973c98-f362-415d-84f5-c930f0260122 	1/22/26, 10:02
bp-5b12dde1-15b5-48dd-8e71-7a4d20260122 	1/22/26, 09:01
bp-881f8aac-b297-4da0-ab4d-90bab0260121 	1/21/26, 14:00
bp-37b59fd0-bf62-486a-b4ff-eda280260116 	1/16/26, 15:39
bp-681db84b-5815-4794-b5f7-14f610260115 	1/15/26, 14:00
bp-40738cdd-04b5-4831-8f18-2f47f0260114 	1/14/26, 15:29
bp-b431c7a9-b9bd-446b-aa47-72be60260114 	1/14/26, 14:03
bp-182e438f-5ea1-4c46-8cc5-ad3d20260123 	1/23/26, 10:13
bp-550aea8f-0f99-46c7-960c-586590260123 	1/23/26, 10:13
bp-82274fa4-ec49-49b8-ba3c-85e160260123 	1/23/26, 10:13
bp-5c30c4b5-394e-4e07-a44e-025db0260123 	1/23/26, 10:13

BTW I just had two consecutive meetings in a row (first Meet then Teams) without a crash, so it's 100% reproducible as I stated earlier. But, as you can see by the amount of crash reports, it has been happening a lot...

Also, it is worth noticing that I tested it on a new, clean profile, and was able to reproduce the crash on the second consecutive Google Meet meeting.

Comment 7

[André Costa]

Attachment: about:support info

Comment 8

[André Costa]

(In reply to Jan Grulich from comment #5)

Hi, can you please run Firefox with MOZ_LOG=webrtc_trace:5 and go to e.g. https://mozilla.github.io/webrtc-landing/gum_test.html to try to reproduce the issue? Or does it happen only with Google Meet? Can you please attach the output here after you reproduce the issue?

This looks like somehow a video format is announced, that we don't support, but it somehow still slips through and results into hitting the assert.

Hi Jan, I could not reproduce the issue with this specific setup (I tried with the clean profile I mentioned on the previous message). I'll attach the console output anyway. I'll repeat the tests with MOZ_LOG=webrtc_trace:5, but this time with Google Meet. Answering your question: I've experienced the crash both with Google Meet and MS Teams (our org uses Google Workspace, but our main client uses MS Teams, so I keep jumping between one and the other many times during the day).

Comment 9

[André Costa]

Attachment: output of tests with gum_test.html (unable to reproduce the crash)

Comment 10

[Jan Grulich]

Hi André, I thought the issue would be reproducible elsewhere. Can you please reproduce the crash with Google Meet then and provide the same output?

Comment 11

[André Costa]

As I was creating a new Google Meet meeting (on a different profile) to test further, this other profile crashed. The crash report is bp-5cca3734-b53f-4e8b-b9d2-7f0430260123

This was something new: it was as if one profile could be "poisoning" another profile. I do my meetings on a Work profile (where I had those two meetings today that I mentioned before), and this crash was on my Personal profile, on which I hadn't done any meetings so far.

Comment 12

[André Costa]

(In reply to Jan Grulich from comment #10)

Hi André, I thought the issue would be reproducible elsewhere. Can you please reproduce the crash with Google Meet then and provide the same output?

I just did it (crash report bp-c61712f5-7544-4aa2-acb7-3e8d80260123). Same behavior: first meeting opened just fine, second meeting crashed right before opening the camera preview. I'll attach the output.

Comment 13

[André Costa]

Attachment: Firefox Google Meet crash with debug info

Comment 14

[André Costa]

Not to sidetrack the discussion, but the 3.0 load during meetings also doesn't seem normal to me on such new and capable hardware (I don't know which codec Google Meet uses, but the Radeon 890M is reportedly able to hardware decode H264, VP9, Av1 and HEVC, and hardware encode H264, AV1 and HEVC)

Comment 15

[André Costa]

(In reply to André Costa from comment #12)

I just did it (crash report bp-c61712f5-7544-4aa2-acb7-3e8d80260123). Same behavior: first meeting opened just fine, second meeting crashed right before opening the camera preview. I'll attach the output.

I could not reproduce the problem with MS Teams this time (I successfully started many consecutive short meetings consecutively), but I am pretty sure it has happened before. I'll upload the output anyway, for the record.

Comment 16

[André Costa]

Attachment: unsuccessful attempt to reproduce the crash with MS Teams

Comment 17

[Jan Grulich]

I can reproduce it now, that will make it easier to debug.

Comment 18

[André Costa]

Sorry for the "comment flood", but I guess the more information you get, the easier it might be to track down the root-cause: I was on a Google Meet a couple of minutes ago, and I lost network connection; the meeting video feed went dark with the "reconnecting" message, as expected, but as soon as the connection was restored and Meet tried to display the camera feed again, it crashed (id bp-607b5d80-6e2f-4ab7-842d-6ddb20260123). So, it's not only when starting a new meeting, it seems to be related to re-displaying the camera feed.

Comment 19

[Jan Grulich]

Thanks for the additional information, but I already have everything I need and in fact I have a fix for this issue. I will submit it first to WebRTC and backport to Firefox. I can also do a Fedora build in case you want to test it.

Comment 20

[Martin Stránský [:stransky] (ni? me)]

(In reply to Jan Grulich from comment #19)

Thanks for the additional information, but I already have everything I need and in fact I have a fix for this issue. I will submit it first to WebRTC and backport to Firefox. I can also do a Fedora build in case you want to test it.

Jan, please do Fedora backports - we have reports from distro users about this one.
Thanks.

Comment 21

[Jan Grulich]

Attachment: Bug 2012006 - WebRTC backport: PipeWire capture: clear existing capabilities before re-enumeration r=pehrsons

Prevent duplicate capability entries by clearing the capabilities vector
before re-enumerating node formats.

This is a simple backport of an WebRTC upstream change.

Upstream commit: TBD

Comment 22

[Jan Grulich]

Fedora backport: https://src.fedoraproject.org/rpms/firefox/pull-request/99
WebRTC change: https://webrtc-review.googlesource.com/c/src/+/443382

Once the WebRTC change is merged and reviewed, I will update the Firefox change here: https://phabricator.services.mozilla.com/D280359

@stransky will you double-check the Fedora MR and merge it all the way to stable branches?

Comment 23

[André Costa]

(In reply to Jan Grulich from comment #19)

Thanks for the additional information, but I already have everything I need and in fact I have a fix for this issue. I will submit it first to WebRTC and backport to Firefox. I can also do a Fedora build in case you want to test it.

That is great news! \o/ Thanks for the prompt reaction, this bug is a showstopper for those depending on Firefox for meetings, a fix is much needed. I'd be more than happy to test a Fedora build if it helps you ensure all is good, but I can also wait for a 147.x patch, no problem.

Comment 24

[Jan Grulich]

(In reply to André Costa from comment #23)

(In reply to Jan Grulich from comment #19)

Thanks for the additional information, but I already have everything I need and in fact I have a fix for this issue. I will submit it first to WebRTC and backport to Firefox. I can also do a Fedora build in case you want to test it.

That is great news! \o/ Thanks for the prompt reaction, this bug is a showstopper for those depending on Firefox for meetings, a fix is much needed. I'd be more than happy to test a Fedora build if it helps you ensure all is good, but I can also wait for a 147.x patch, no problem.

Here is a scratch build for Fedora 43: https://koji.fedoraproject.org/koji/taskinfo?taskID=141523010.
Give it some time to build, then once it is green you should be able to download RPMs.

Comment 25

[André Costa]

(In reply to Jan Grulich from comment #24)

Here is a scratch build for Fedora 43: https://koji.fedoraproject.org/koji/taskinfo?taskID=141523010.
Give it some time to build, then once it is green you should be able to download RPMs.

I just installed it, and it seems to fix the issue indeed: I left and rejoined multiple consecutive test meetings, started new ones etc. all within the same browser instance, not a single crash. Nice work @jan!

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/21710002e9da
https://hg.mozilla.org/integration/autoland/rev/3905f189b8ac
WebRTC backport: PipeWire capture: clear existing capabilities before re-enumeration r=pehrsons

Comment 27

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/3905f189b8ac