libvlc_media_player_stop deadlock

[brma]

Hi!
I'm using libvlc 2.0.4 in a Qt 4.7 application. The integration was easy and it works well most of the time. The application streams data from a network camera using RTSP/RTP in both h264 video and aac audio.

Sometime however, the application freeze on a call to libvlc_media_player_stop.

I've tried several configuration of outputs :
default direct 3d
glwin32

Differents inputs (with both H264/AAC):
RTSP/RTP from Axis camera
RTSP/RTP from live555 media server
mkv

Different program paths:
allocate a new player instance for each play
Reuse the same instance
Try to free player without stopping (deadlock with a similar stack trace for thread 0)

So my conclusions for the moment are that the problem is unrelated to the input plugin nor to the output plugin but libvlccore locks when releasing these resources.

I created a simple program witch is close to the sample provided with the SDK. Given time, it will deadlock in the same way as my application does. It includes a sample video. My app doesn't stop and start as frequently as this program but the purpose here is to reproduce the bug as fast as possible.
File is located there : https://bugzillainc.averna.com/share/video_ui_test.7z
On my system, it is compiled with Qt 4.7.1 and windows sdk 7.1. My current target is x64 but I saw the same bug on win32.

I included the stack traces captured from QtCreator. I know its not gdb traces but i'm not (yet) capable of compiling libvlc with debug symbol on my own.

Any help on this bug would be greatly appreciated.
Thanks and regards,
Bruno Marchand



Thread 0
0 ZwWaitForMultipleObjects ntdll 0x77c118ca
1 WaitForMultipleObjectsEx KERNELBASE 0x7fefd501420
2 WaitForMultipleObjectsExImplementation kernel32 0x77652cf3
3 vlc_poll libvlccore 0x61e5226c
4 vlc_join libvlccore 0x61e52bb2
5 vout_Close libvlccore 0x61e17981
6 input_resource_Release libvlccore 0x61e0881d
7 input_resource_TerminateVout libvlccore 0x61e08ff9
8 libvlc_media_player_stop libvlc 0x7405abe6
9 VideoPlayWidget::setUrl video_play_widget.cpp 68 0x13f1a2deb
10 MainWindow::unsetIp mainwindow.cpp 33 0x13f1a15ef
11 MainWindow::qt_metacall moc_mainwindow.cpp 77 0x13f1a3246
12 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x59698de4
13 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x596b5380
14 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x597532e0
15 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x596c5445
16 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x596b0792
17 QAction::isOn QtGuid4 0x51eefc66
18 QAction::isOn QtGuid4 0x51eecd61
19 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x5968d49a
20 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x59693a03
21 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x596e0427
22 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x596dfe39
23 UserCallWinProcCheckWow USER32 0x77ad9bd1
24 DispatchMessageWorker USER32 0x77ad98da
25 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x596e127e
26 QAction::isOn QtGuid4 0x51fd91d5
27 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x5968a804
28 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x5968a989
29 QPersistentModelIndex::~QPersistentModelIndex QtCored4 0x5968db5c
30 QAction::isOn QtGuid4 0x51eec908
31 main main.cpp 15 0x13f1a122e
32 WinMain qtmain_win.cpp 131 0x13f1a4c61
33 __tmainCRTStartup crtexe.c 547 0x13f1a40a6
34 WinMainCRTStartup crtexe.c 371 0x13f1a3d9e
35 BaseThreadInitThunk kernel32 0x7764652d
36 RtlUserThreadStart ntdll 0x77bec521

Thread 1
0 ZwWaitForMultipleObjects ntdll 0x77c118ca
1 WaitForMultipleObjectsEx KERNELBASE 0x7fefd501420
2 WaitForMultipleObjectsExImplementation kernel32 0x77652cf3
3 vlc_poll libvlccore 0x61e5226c
4 vlc_cond_wait libvlccore 0x61e5284d
5 intf_Create libvlccore 0x61de19ff
6 vlc_sem_wait libvlccore 0x61e52c42
7 endthreadex msvcrt 0x7fefef6415f
8 endthreadex msvcrt 0x7fefef66ebd
9 BaseThreadInitThunk kernel32 0x7764652d
10 RtlUserThreadStart ntdll 0x77bec521

Thread 2
0 ZwWaitForMultipleObjects ntdll 0x77c118ca
1 TppWaiterpThread ntdll 0x77bdb007
2 BaseThreadInitThunk kernel32 0x7764652d
3 RtlUserThreadStart ntdll 0x77bec521

Thread 3
0 ZwWaitForMultipleObjects ntdll 0x77c118ca
1 WaitForMultipleObjectsEx KERNELBASE 0x7fefd501420
2 WaitForMultipleObjectsExImplementation kernel32 0x77652cf3
3 vlc_poll libvlccore 0x61e5226c
4 vlc_join libvlccore 0x61e52bb2
5 vlc_entry_license__1_2_0l libdirect3d_plugin 0x60305fa3
6 vlc_entry_license__1_2_0l libdirect3d_plugin 0x60306795
7 libdirect3d_plugin 0x60301971
8 vlc_module_unload libvlccore 0x61e35a78
9 vout_DeleteDisplay libvlccore 0x61e12a96
10 vout_EnableFilter libvlccore 0x61e1f6bd
11 vout_NewDisplay libvlccore 0x61e14fc4
12 vout_NewDisplay libvlccore 0x61e17263
13 vlc_sem_wait libvlccore 0x61e52c42
14 endthreadex msvcrt 0x7fefef6415f
15 endthreadex msvcrt 0x7fefef66ebd
16 BaseThreadInitThunk kernel32 0x7764652d
17 RtlUserThreadStart ntdll 0x77bec521

Thread 4
0 NtUserMessageCall USER32 0x77ad685a
1 RealDefWindowProcWorker USER32 0x77ad68a2
2 RealDefWindowProcA USER32 0x77acb96d
3 DefWindowProcA USER32 0x77acb900
4 vlc_entry_license__1_2_0l libdirect3d_plugin 0x603047f2
5 UserCallWinProcCheckWow USER32 0x77ad9bd1
6 DispatchClientMessage USER32 0x77ad72cb
7 _fnDWORD USER32 0x77ad6829
8 KiUserCallbackDispatcherContinue ntdll 0x77c11225
9 NtUserMessageCall USER32 0x77ad685a
10 RealDefWindowProcWorker USER32 0x77ad68a2
11 RealDefWindowProcA USER32 0x77acb96d
12 DefWindowProcA USER32 0x77acb900
13 vlc_entry_license__1_2_0l libdirect3d_plugin 0x603048e4
14 UserCallWinProcCheckWow USER32 0x77ad9bd1
15 DispatchClientMessage USER32 0x77ad72cb
16 _fnDWORD USER32 0x77ad6829
17 KiUserCallbackDispatcherContinue ntdll 0x77c11225
18 NtUserGetMessage USER32 0x77ad9e6a
19 GetMessageA USER32 0x77ad615e
20 vlc_entry_license__1_2_0l libdirect3d_plugin 0x60305139
21 vlc_sem_wait libvlccore 0x61e52c42
22 endthreadex msvcrt 0x7fefef6415f
23 endthreadex msvcrt 0x7fefef66ebd
24 BaseThreadInitThunk kernel32 0x7764652d
25 RtlUserThreadStart ntdll 0x77bec521

Thread 5
0 NtWaitForWorkViaWorkerFactory ntdll 0x77c12c1a
1 TppWorkerThread ntdll 0x77bdfe0b
2 BaseThreadInitThunk kernel32 0x7764652d
3 RtlUserThreadStart ntdll 0x77bec521

Thread 6
0 DbgBreakPoint ntdll 0x77c10530
1 DbgUiRemoteBreakin ntdll 0x77cb7ef8
2 BaseThreadInitThunk kernel32 0x7764652d
3 RtlUserThreadStart ntdll 0x77bec521

[Rémi Denis-Courmont]

The top of most of your stack frames are invalid, so personally I cannot pinpoint what got stuck.

What I can guess though:

• Thread 0 is your main UI thread, and stuck waiting for the VLC input thread to complete.
• Thread 1 symbolic trace is garbage. By elimination, I suppose it is the VLC input thread. It is evidently stuck waiting for some event.
• Thread 2 does not seem to be a VLC thread at all. It is also stuck.
• Thread 3 is the VLC video output thread. It is stuck while unloading the Direct3D plugin. The top of the symbolic trace is garbage but most probably this thread is stuck waiting for thread 4 to terminate.
• Thread 4 is probably the Direct3D message loop and is stuck delivering a Windows message.
• Thread 5 does not seem to be a VLC thread.
• Thread 6 seems to be a debugger.

Your UI thread might have deadlocked itself by not answering the messages from the VLC Direct3D window.

[brma]

Hi Rémi,
Thanks for your quick reply. Your understanding of the threads is right, Thread 0 being the main thread and the Qt event loop thread.

From your answer, the way I implemented the app could be the cause of the deadlock. I'm not sure about the message answering though. Should I call vlc stop from another thread, or is there a callback to implement and register somewhere?

Bruno

[eli13]

Hello brma and Rémi

I have the very same problem - I use libVLC 2.0.4 to play four RTSP/RTP Streams.

Sometimes calling libvlc_media_player_stop will deadlock vlc. The chances of deadloking are higher on "old" (slower C-Runtime? Windows XP SP2) machines.

I use libVLC from withing VC++ 90. I cannot provide a (useable) stacktrace as I dont have working libVLC dlls with symbols.

Are there any workarounds? I do not call any libvlc_* from the vlc-event-callback-thread.

@brma:
In an old post from 2009 it is mentioned that removing the window-handle before calling media_player_stop helps to avoid the deadlock. Well, the thread is about Delphi and vlc 1.x.. (If I understand it right: viewtopic.php?f=32&t=62504&start=0&hilit=delphi ). Could you give that maybe a try brma? I dont have a setup here that allows me to reproduce it easily (Cannot access cameras from here).

Thanks for any help

[Rémi Denis-Courmont]

Without stack trace, I have to assume your application is locking itself up. The solution is to fix your code. Sorry but this forum is about LibVLC, not multithread programming 101.

[eli13]

Rémi, I understand your point of view. Well, it does not lock itself up - all blocked threads are from within libvlc.dll, waiting on something, as my gui-thread calls libvlc_stop which does not return it is blocked too.

I'll provide a stacktrace.

[Rémi Denis-Courmont]

That does not prove anything. The stack trace posted above shows that the video output thread is blocked in DefWindowProc(), not in VLC...

[brma]

Hi eli and Rémi,
I followed Rémi's advice : "Your UI thread might have deadlocked itself by not answering the messages from the VLC Direct3D window."
I moved all the libvlc interactions on a second event loop. So the widget "lives" on the main event loop and vlc interactions on a secont Qt event loop. The communication between the two is through events with Qt::QueuedConnection.
I can't tell if it definitely fix this specific problem, but I ran 7 UIs in 7 processes on two different computers and it worked for more than 12 hours, no deadlock. So I consider this problem solved.
Thanks a lot Rémi for pointing me problem.
Should this information be part of the sdk examples or documentation? At first glance, I did not expect such a complex relation between the main event loop, the WId passed to vlc and the direct3d code.

Thanks and Regards,
Bruno

[Rémi Denis-Courmont]

If someone understands the subtleties and implications of Windows messages, patch is welcome.

[brma]

Hi Rémi,
I updated the QtPlayer found under "doc\libvlc\QtPlayer" in the source archive. I implemented the dual event loop solution I use to solve my deadlock issue.
It compile under windows with msvc2010 and under linux. I haven't linked under Linux though as I have an outdated ubuntu 10.04 system.
I tried it with vlc 2.0.4

The file is there: https://bugzillainc.averna.com/share/QtPlayer.7z

Thanks again for all your good work,
Bruno

[eli13]

Thank you both for the help!

Not calling libvlc_XY from the gui-thread solved the issue (well, at least I wasn't able to reproduce it). I now simply start a thread to do the calls, it seems it is no problem for vlc if it receives its orders from different threads all over..

[Alexolut]

Sometimes the call libvlc_media_player_stop() function in GUI-thread leads to deadlocks. And it happens on an almost empty application. There is only the main form with control (like a panel), which carried the image output (assign through libvlc_media_player_set_hwnd()). Timer periodically (every 5 seconds) is called stop() and play(). No more functionality in that simple program. If the mouse to click on the associated control, then hang appears faster.

My solution is to call the stop() from the new thread and wait for its completion (via join ()). If the wait timeout set, before calling play(), you must ensure that the playing is done (check the return value of libvlc_media_player_get_state()). If you do call play() again, you will see a new window with video (as happens if you do not bind the output through libvlc_media_player_set_hwnd()).

Perhaps this message will be helpful.

[hvz]

I found something that might be useful for other people who run into this issue. If you're feeding VLC with audio through IMEM, and you call libvlc_media_player_stop, it will NOT return unless you return some data via IMEM. If (as would be logical) you just reply that you have 0 bytes of data available, the stop call will deadlock. Just sending 1 sample (for each channel) containing a 0 fixes this deadlock.