Bug 284718 – Playing voice messages on WhatsApp freezes the system

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Angelo Schirinzi]

This is an issue that in the past only caused the browser or web page to freeze, but recently it has ended up causing the entire system to freeze.
The peculiarity of this issue is that it occurs if you use the Epiphany rpm (Fedora Workstation) package but not if you use the flatpak version (tested the TP version on GNOME OS).
To reproduce it, you just need to be on a Fedora system, have the plugins for all multimedia formats installed (including those available via RPM Fusion) and run WhatsApp from the Epiphany web browser (rpm package).

[Philippe Normand]

Can you share logs please? https://docs.webkit.org/Ports/WebKitGTK%20and%20WPE%20WebKit/Multimedia.html

[Angelo Schirinzi]

(In reply to Philippe Normand from comment #1)
> Can you share logs please?
> https://docs.webkit.org/Ports/WebKitGTK%20and%20WPE%20WebKit/Multimedia.html

Since the log file produced is 20 GB in size, I am attaching just a piece of it (I believe it corresponds to the first 37 seconds; if so, then it must contain traces of what happened), which I hope contains valuable information.

[Angelo Schirinzi]

Created attachment 473577 [details]
Partial log file 1

[Philippe Normand]

20 GB? How many hours did you leave this on? The file shouldn't be that big.

I don't see nothing out of the ordinary in the one shared above.
I can't reproduce this issue here, and memory usage remains stable when playing audios.

The fact that it happens only in the rpm version suggests some issue that was fixed in flatpak version but not yet in the distro.

[Angelo Schirinzi]

(In reply to Philippe Normand from comment #4)
> 20 GB? How many hours did you leave this on? The file shouldn't be that big.
> 
> I don't see nothing out of the ordinary in the one shared above.
> I can't reproduce this issue here, and memory usage remains stable when
> playing audios.
> 
> The fact that it happens only in the rpm version suggests some issue that
> was fixed in flatpak version but not yet in the distro.

It stayed active until I was able to unlock and shut down the computer. I think about forty minutes in all.

I don't see what might not have been updated in the distro since GStreamer is updated to the latest version (as is WebKit).

I don't know what else to do... Can you try Fedora in VM (if so, I remind you that I use all the plugins installable with `sudo dnf install Multimedia --allowerasing`, including those of RPM Fusion)?
Or suggest me what else to do...

[Angelo Schirinzi]

Sorry in F41 it's `sudo dnf group install multimedia --allowerasing`

[Michael Catanzaro]

(In reply to Philippe Normand from comment #4)
> The fact that it happens only in the rpm version suggests some issue that
> was fixed in flatpak version but not yet in the distro.

Unless we have some particular reason to believe otherwise, I fear the opposite is more likely. Stable Fedora is generally ahead of stable freedesktop-sdk, the bug could be coming soon to a Flatpak runtime near you.

Or there could just be some sort of other behavior difference.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #7)
> Or there could just be some sort of other behavior difference.

(Notably, the Epiphany flatpak has a much more limited set of GStreamer plugins available than Fedora + RPM Fusion.)

[Angelo Schirinzi]

Since playing Opus audio files on other websites works great, could we assume that the problem is in how WebKit interacts with WhatsApp's media player? Maybe GStreamer has nothing to do with it after all... If that's the case I could edit the title and reconsider the problem from a different point of view...

[Radar WebKit Bug Importer]

<rdar://problem/141914695>

[Angelo Schirinzi]

Today I tried to do some tests and everything was working fine, until I tried to turn up the volume while listening to the voice message and I fell into the usual bug (the system froze). I don't know if this can suggest anything.

[Angelo Schirinzi]

Here some pipewire tracks from journalctl (nothing else of relevance):


pw.node: (alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Speaker__sink-52) graph xrun not-triggered (3 suppressed)

pw.node: (alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Speaker__sink-52) xrun state:0x7fd143598008 pending:8/1 s:14466475642718 a:14466475713175 f:14466475723336 waiting:70457 process:10161 status:triggered

pw.node: (alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Speaker__sink-52) graph xrun not-triggered (2 suppressed)

pw.node: (alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Speaker__sink-52) xrun state:0x7fd143598008 pending:8/2 s:14474158030047 a:14474158081091 f:14474158091330 waiting:51044 process:10239 status:triggered

pw.node: (alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Speaker__sink-52) graph xrun not-triggered (6 suppressed)

pw.node: (alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Speaker__sink-52) xrun state:0x7fd143598008 pending:8/1 s:14486067763385 a:14486067767554 f:14486067784365 waiting:4169 process:16811 status:triggered

[Angelo Schirinzi]

And these:

gnome-shell[2466]: Value -9223372036854775808 cannot be safely stored in a JS Number and may be rounded


gnome-shell[2466]: Sink callback failure

[Angelo Schirinzi]

On Epiphany 47.4 and WebKitGTK 2.48.1 I no longer reproduce the issue (GStreamer 1.24.11). Probably the new major release of WebKit has unintentionally patched it. Maybe (in the meantime the new version of Pipewire has also shipped). Anyway, since no other user has reported the same issue, I think it can be closed.