Bug 261264 – [GTK][GStreamer] Crash when clicking play button after video ended

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Kdwk]

Created attachment 467581 [details]
gdb (t a a bt; c) output.txt

Transferred from https://gitlab.gnome.org/GNOME/epiphany/-/issues/2171. I have now found a way to reproduce the crash

1. Visit https://tools.woolyss.com/html5-audio-video-tester/?u=woolyss.com/f/caminandes-3-llamigos-x265-aac.mp4
2. Play the video until its end
3. Press play
4. WebProcess crash. 'App not responding' dialog appears

[Philippe Normand]

in gdb can you type this?

thread 14
f 2
p *mutex

and then:

into threads

[Philippe Normand]

I cannot reproduce this issue here btw, in TP, without or without VA decoders.

[Kdwk]

Created attachment 467582 [details]
gdb (thread 14; f 2; p *mutex; into threads) output.txt

[Michael Catanzaro]

(In reply to Philippe Normand from comment #2)
> I cannot reproduce this issue here btw, in TP, without or without VA
> decoders.

I can't reproduce it either (did not try VA decoders).

[Kdwk]

Created attachment 467583 [details]
gdb (thread 14; f 2; p *mutex; into threads) output 2

I triggered the bug again and re-did the gdb commands, and the output was different

[Philippe Normand]

I was asking about the first crash report... Load it in gdb again and type the commands.

[Kdwk]

How do I load it in gdb again?

[Kdwk]

(I was under the impression that it gets overridden every time there's a new crash)

[Philippe Normand]

coredumps accumulate and periodically get cleaned up (by systemd or something). So look it up with `coredumpctl list`, get the PID and then run `coredumpctl gdb <pid goes here without brackets>`

[Kdwk]

Is there a way to do that with flatpak-coredumpctl? I use Epiphany Tech Preview in Flatpak, so coredumpctl gdb just says ?? ()

[Philippe Normand]

(In reply to Kdwk from comment #10)
> Is there a way to do that with flatpak-coredumpctl? I use Epiphany Tech
> Preview in Flatpak, so coredumpctl gdb just says ?? ()

flatpak-coredumpctl -h mentions a -m option, so use it?

[Kdwk]

I'm afraid I couldn't make it work. Perhaps I could trigger the crash again and give you a new gdb (t a a bt; c) output.

[Kdwk]

Created attachment 467599 [details]
gdb (t a a bt; c) output 2.txt

This is another gdb output after freshly triggering the bug. I did not quit gdb so if you would like to see the output of some other gdb command I can still get it

[Philippe Normand]

t 5
f 2
p *mutex

[Kdwk]

(gdb) t 5
[Switching to thread 5 (Thread 0x7f6362ad4a00 (LWP 2))]
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38		cmpq $-4095, %rax	/* Check %rax for error.  */
(gdb) f 2
#2  0x00007f6366478477 in g_mutex_lock (mutex=mutex@entry=0x55c691d94418)
    at ../glib/gthread-posix.c:1417
1417	    g_mutex_lock_slowpath (mutex);
(gdb) p *mutex
$1 = {p = 0x2, i = {2, 0}}

[Philippe Normand]

Damn this isn't a pthread mutex, can't see the owning thread :(

[Michael Catanzaro]

If we could reproduce the crash then we could probably force/hack GLib to use pthread mutexes somehow, or get a GStreamer debug log. But we'll never find a reproducer. So I don't know what to do.

I've never seen a deadlock like this before. :( Normally it's obvious from the backtrace which threads might have the mutex locked. But here, every thread looks innocent. The only other thread using GStreamer at all is thread 25.

[Philippe Normand]

Maybe this is specific to nvidia?

Can you get logs? GST_DEBUG="3,webkit*:7"

[Philippe Normand]

Is this still happening with 2.46.1?

[Kdwk]

No, the video correctly plays again from the start.