UI becomes unresponsive, almost unkillable after some time

I can reliably reproduce this in version 3.0.3:

1. Start playing a video in VLC.
2. Leave VLC running for some time (playing or paused). It is unknown how long it takes to trigger this, but it's 100% reliable if left running overnight, and I believe I've managed to reproduce after leaving the player running for just an hour or so.
3. Close VLC using Ctrl-q.

At this point the screen stays black if VLC was full screened and the video finished. If VLC was not full screened the UI disappears. In both cases the process does not terminate. killall vlc is not enough to terminate it; I've had to use SIGKILL.

MissingTrace

added Status::needs more info label

closed

Full stack after pressing Ctrl-q and the UI becomes unresponsive:

(gdb) bt full
[#0](https://code.videolan.org/videolan/vlc/-/issues/0)  0x00007f2336e89f6d in __pthread_timedjoin_ex () at /usr/lib/libpthread.so.0
[#1](https://code.videolan.org/videolan/vlc/-/issues/1)  0x00007f232a9b6502 in  () at /usr/lib/vlc/plugins/gui/libqt_plugin.so
[#2](https://code.videolan.org/videolan/vlc/-/issues/2)  0x00007f2336bd656e in vlc_module_unload () at /usr/lib/libvlccore.so.9
[#3](https://code.videolan.org/videolan/vlc/-/issues/3)  0x00007f2336bdd181 in  () at /usr/lib/libvlccore.so.9
[#4](https://code.videolan.org/videolan/vlc/-/issues/4)  0x00007f2336bbf34f in libvlc_InternalCleanup () at /usr/lib/libvlccore.so.9
[#5](https://code.videolan.org/videolan/vlc/-/issues/5)  0x00007f2336eab31b in libvlc_release () at /usr/lib/libvlc.so.5
[#6](https://code.videolan.org/videolan/vlc/-/issues/6)  0x0000559d0349a337 in  ()
[#7](https://code.videolan.org/videolan/vlc/-/issues/7)  0x00007f2336cdc223 in __libc_start_main () at /usr/lib/libc.so.6
[#8](https://code.videolan.org/videolan/vlc/-/issues/8)  0x0000559d0349a41e in  ()

Please let me know if you need more information.

PS: Neither https://trac.videolan.org/vlc/wiki/MissingTrace nor the linked https://wiki.videolan.org/Report_bugs contain detailed information on how to produce traces

removed Status::needs more info label

reopened

(Adding this here because it's probably a related issue)

Sometimes when drag and dropping a file onto VLC it hangs, and also has to be SIGKILLed. Trace:

(gdb) bt
[#0](https://code.videolan.org/videolan/vlc/-/issues/0)  0x00007fe27b0e7b4c in sigtimedwait () at /usr/lib/libc.so.6
[#1](https://code.videolan.org/videolan/vlc/-/issues/1)  0x00007fe27b289f4d in sigwait () at /usr/lib/libpthread.so.0
[#2](https://code.videolan.org/videolan/vlc/-/issues/2)  0x0000557bf6e562cc in  ()
[#3](https://code.videolan.org/videolan/vlc/-/issues/3)  0x00007fe27b0d3223 in __libc_start_main () at /usr/lib/libc.so.6
[#4](https://code.videolan.org/videolan/vlc/-/issues/4)  0x0000557bf6e5641e in  ()

Neither the bug description, nor the incomplete trace show what the problem is. Still MissingTrace.

added Status::needs more info label

closed

If gdb's bt full isn't sufficient, what is? Please, The linked documentation does not explain in any detail what is required, and I really hope to resolve this.

Upstream package build description

Added attachment:

• PKGBUILD.orig

Build file used for debugging

Added attachment:

• PKGBUILD

gdb vlc output

Added attachment:

• gdb.log

I built VLC 3.0.3 with the attached PKGBUILD (modified according to the debug build instructions helped by https://unix.stackexchange.com/q/465709/3645), ran gdb vlc, and reproduced the issue. Please find the complete gdb log attached.

Please let me know if you want a full core dump as well.

As per the instructions, stack traces must symbolic and threaded, otherwise they are almost certainly useless.

How?!? I have now spent about 12 hours on this report! I've compiled a debug version according to the best of my own and Unix Stack Exchange's understanding, and I've sent you every single line printed by that debug version when encountering the bug. What is missing? Surely this should be a well understood process, and you could explain or link to an explanation that would make sense to someone who is not part of the VLC project, but nevertheless has more than 10 years' experience as a software developer.