[GStreamer][MSE] Crashes on https://www.apple.com/macbook-air-13-and-15-m2/

[Kdwk]

**
ERROR:../gst/codecalpha/gstalphacombine.c:160:gst_alpha_combine_unlock_stop: assertion failed: (self->flushing)
Bail out! ERROR:../gst/codecalpha/gstalphacombine.c:160:gst_alpha_combine_unlock_stop: assertion failed: (self->flushing)

(epiphany:2): epiphany-WARNING **: 18:35:48.591: Web process crashed




This is tested on Epiphany Technology Preview/ WebKitGTK 2.41.6, it worked fine in 2.41.5

[Michael Catanzaro]

Since you've been reporting bugs for a while, I'm sure by now you know how to take a backtrace with gdb and a GStreamer debug log, right?

Instructions for the debug log: https://trac.webkit.org/wiki/WebKitGTK/Debugging#Debuggingmultimediastuff

[Kdwk]

Unfortunately, from experience, the backtrace just says n/a whatever I do. I’ll try to get the GStreamer logs…

[Michael Catanzaro]

If you have org.gnome.Sdk.Debug installed and at the same version as your org.gnome.Platform, then it shouldn't say n/a. If it does, that's a runtime bug. Unfortunately I've also found that our debuginfo breaks sometimes, but it shouldn't be *always* broken, so I would try it and see.

[Kdwk]

Created attachment 466945 [details]
flatpak-coredumpctl backtrace

Here is a requested backtrace

[Kdwk]

Created attachment 466969 [details]
Updated flatpak-coredumpctl backtrace

Here is the updated full backtrace

[Michael Catanzaro]

Can you show a backtrace for all threads, please? Use `t a a bt` as suggested on Matrix.

That said, there are no WebKit frames in this backtrace so we might have to move this to GStreamer's issue tracker. Let's see what Phil thinks after you show all threads.

[Kdwk]

Created attachment 466974 [details]
All-threads backtrace

Here's the requested all-threads backtrace

[Kdwk]

Created attachment 466976 [details]
All-threads backtrace (fixed)

Here's the requested all-threads backtrace

[Alicia Boya García]

(In reply to kdwkleung from comment #0)
> **
> ERROR:../gst/codecalpha/gstalphacombine.c:160:gst_alpha_combine_unlock_stop:
> assertion failed: (self->flushing)
> Bail out!
> ERROR:../gst/codecalpha/gstalphacombine.c:160:gst_alpha_combine_unlock_stop:
> assertion failed: (self->flushing)
> 
> (epiphany:2): epiphany-WARNING **: 18:35:48.591: Web process crashed
> 
> 
> 
> 
> This is tested on Epiphany Technology Preview/ WebKitGTK 2.41.6, it worked
> fine in 2.41.5

I heavily suspect this is https://bugs.webkit.org/show_bug.cgi?id=244776 in action. In fact, it's the same outcome: an element downstream of decodebin3 (in this case alphacombine) is receiving a FLUSH_STOP without receiving a FLUSH_START.

I first was made aware of this happening from seeing a similar assertion failing in WebKitVideoSink after it was corrected to use AbortableTaskQueue, and therefore able to handle flushes. I think most people didn't care much about it because it WebKit debug assertions get stripped for release builds.

I've long deduced the race condition is in core GStreamer elements and cannot be easily fixed in WebKit alone. Since a few weeks ago I've finally been able to dedicate more time to investigating this race condition.

I've made good progress on that: I found it's not just one race condition, but several similar races in several elements: decodebin3, playsink and playsinkconvertbin. I've also been able to fix them locally, and I'm currently working towards verifying and upstreaming them.

Unfortunately that also means it's not an easy task and the fixes need not only to be approved in upstream GStreamer but will require new GStreamer versions or GStreamer patches in flatpak.

[Alicia Boya García]

*** This bug has been marked as a duplicate of bug 244776 ***