Bug 261264

in gdb can you type this? thread 14 f 2 p *mutex and then: into threads

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

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

(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).

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

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

How do I load it in gdb again?

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

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>`

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

(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?

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.

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

t 5 f 2 p *mutex

(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}}

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

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.

Maybe this is specific to nvidia? Can you get logs? GST_DEBUG="3,webkit*:7"

Is this still happening with 2.46.1?

No, the video correctly plays again from the start.