The VideoLAN Forums

Hi guys,

I know it's an old topic, but it happens again in vlc 1.1.11, and I am sure I didnot call libvlc_media_player_stop() and libvlc_media_player_play() too close or in different threads simultaneously because I've checked my log.

I've already checked these threads in the forum, but without luck:
viewtopic.php?f=32&t=87932
viewtopic.php?f=2&t=51509

for now the hang happens randomly when my application (which use libvlc to receive http stream) run for a long time (over 12+ hours or even longer). it's pretty OK if it runs for a short time, even stop() and play() repeatedly.

any suggestions?

Same as usual: start the debugger and see where it gets stuck.

Also make sure your own application is not dead-locked. Note in particular that the your application message loop, or whatever you call it, is not run during libvlc_media_player_stop().

Thanks, Remi, for the quick reply.

I've checked with WinDbg and Visual Studio TrackStack to see the actual call stack, nothing unusual.

My own application is not dead-locked, 'cause I added a lock to make sure no thread / method re-entry in the libvlc_media_player_stop() invoke procedure. The lock won't be released until the stop() method is finished and returned.

Every time the deadlock happens it runs a long time so it's quite hard to reproduce.

I am wondering whether to replace WaitForSingleObject with a MsgWaitForMultipleObjects in src/win32/thread.c

I mean to see where it gets stuck inside Libvlc. Obviously it gets stuck at _stop() but there is more to it.

So far, nobody has been able to prove that this was a VLC bug. I thus claim it's a problem with your app. If you need MsgWait, then it definitely is a problem with your app.

Oh, sorry, I misunderstood you.

The stack inside libvlc is as followed, just the same with @solud in this thread: viewtopic.php?f=32&t=87932

ntdll.dll!NtWaitForSingleObject()
kernel32.dll!WaitForSingleObjectEx()
libvlccore.dll!vlc_join()

I'd double check my App and report the result later.

Thanks so much!

That just means it's waiting for another thread. You need to whole threaded stack trace.