VLC freezes under windows XP if player is not in focus

[Razor512]

I will try to keep this as short and detailed as possible.

Under windows XP, If you play any video, and reach the end of the video while the window is not in focus (eg you are working with another program while using VLC)
VLC player will freeze, requiring you to use task manager to close it.

There is no error as the program does not crash, it freezes (not responding)

I have also recorded a video of this issue.

http://www.youtube.com/watch?v=KFZd3UjdNyc
(this happens only under windows XP)

A user by the name of Rémi Denis-Courmont, posted in another thread that a bug report tool can be used but I cant find it anywhere in VLC player.


Additional info:
VLC player 1.1.11
Windows XP SP3 32 bit

[rogerdpack]

Any messages (tools -> messages -> verbosity 2) ?

[Razor512]

it wont let me save the report since it completely freezes but it does not seem to have any error in the message

[df30]

Same problem here.
2 displays, one with vlc fullscreen, unfocused -> vlc crashes when single mediafile ends, very often when there are more files in playlist, too (but not always then, but does not matter if focused or not).
Very very annoying.

And while speaking about annoying things, the latest vlc version is the most unstable one of a program I ever used.
It crashes appr. every 3 files, in different ways. It does not happen always but very often, e.g. when adding file(s) to new opened vlc, or to already open vlc, when clicking next, and so on. vlc just closes as if it weren't open at all, with no message after new start; files will play after trying 1-3 times. Another crash happens with nearly quarter of my files, vlc closes without message, too, but after new start gives message (vlc just crashed, want to send bug report, etc.); files will never play.
3 versions before i did not have such problems, vlc crashed once a week, now 50 times a day. I wonder what happened, that files i can play with older versions cannot be played in the newest, that's very strange. But this is the same with every version, some files which could not be played with old versions could be played with new ones (which is normal), but files which could be played earlier could not anymore (which is more than very odd). But in the past this was with only a handful files, now it is extreme. E.g. nearly 90% of flv makes vlc crash but can be played in nearly every other player without problems, even old vlc. How does it come, that the older a vlc version is, the more stable it is and the more files it can play?!

Another annoying thing is, that vlc can remember all settings but the location of the toolbar-thingy which appears in fullscreenmode, would be nice if you could add/fix this.

[DJ Doena]

I have the same problem.

Specs:

Windows XP Professional 32bit
VLC Player 1.1.11
Dual Monitors

It doesn't matter on which monitor the video is full-screened. When the program is not focussed upon file end, it'll freeze.

[Razor512]

Anyone know if there any additional tools that may help provide more details on the freeze?

Want to provide as much information as possible so that someone may fix it but nothing else in VLC seems to be providing any additional information.

[rogerdpack]

maybe open it with process explorer and see stack traces of where each thread is hanging?

[DJ Doena]

maybe open it with process explorer and see stack traces of where each thread is hanging?

[VLC_help]

Default stack traces given by Windows don't usually help at all. Only gdb seems to give proper ones, even then you need VLC debug versions and crashing VLC.

[rogerdpack]

vlc_cond_wait might imply some type of race condition. Maybe related to viewtopic.php?f=14&t=78337&hilit=+windows+xp#p257507 ?
I'm seemingly unable to "easily" reproduce it here (windows 7), though I only have one monitor maybe that makes a difference?

[DJ Doena]

vlc_cond_wait might imply some type of race condition. Maybe related to viewtopic.php?f=14&t=78337&hilit=+windows+xp#p257507 ?
I'm seemingly unable to "easily" reproduce it here (windows 7), though I only have one monitor maybe that makes a difference?

At home I have two monitors and Win 7 x64 and it works just fine.

[jadew]

Hello, I'm sorry for my absence from my original thread here: viewtopic.php?f=2&t=87934

I stopped using VLC back then, but recently, as I was working on a project of my own and taking care of thread safety, I had an epiphany regarding this issue. Sadly, I didn't had the click, when I posted my last comment on that thread, but I think I have the answer now.

As you might have noticed, on that last reply of mine. I identified the fact that it's freezing after a call to GetMessage.

All this put together can only mean one thing, it's a deadlock. I'm not familiar with the code of VLC, so here's a simplified scenario of what I think it's going on, assuming you're using recursive mutexes:

void UIClass::doSomething()
{
lock_mutex();
SendMessage(WM_SOMETHING); // Or a call to something that will do a SendMessage
unlock_mutex();
}

void UIClass::OnWMSomething()
{
}

void UIClass::OnWMSomething2()
{
lock_mutex();
// something
unlock_mutex();
}


void RandomThread::ScrewUp()
{
UiThread->doSomething();
}


If you were to do SendMessage(WM_SOMETHING2); from doSomething() it is pretty clear how the code would fail. Giving the age of the project, I think that bug would have been found at the development stage, due to it's constant and certain generation of deadlocks. So I think you're actually doing SendMessage(WM_SOMETHING); - no mutex locks in its handler, but that doesn't prevent it from being wrong.

WM_SOMETHING could actually be any window message.


once ScrewUp() is called the following things will happen:

1) the mutex in question will get locked for the current RandomThread, inside UIClass::doSomething()
2) SendMessage will send WM_SOMETHING message and will wait for it to finish processing
3) OnWMSomething() will run on the UI Thread.
4) OnWMSomething() will return
5) the mutex will get unlocked inside UIClass::doSomething()

Q: Why is it wrong?
A: Because you're sending messages from inside a critical section.

Q: How can this cause the freeze?
A:
- Consider that at that point, the conditions are just right for messages to be sent to the message loop, outside of the RandomThread.
- Now consider that one of those messages gets handled between step 1 and step 2 AND that the message handler is locking the mutex.
- The result is that the message handler starts waiting for UIClass::doSomething() to finish, just before UIClass::doSomething() sends the non important message to the message loop and starts waiting for it. Message that will never get processed, because the message loop is stuck processing the previous message.

Example of non related message handler that can cause the freeze:
void UIClass::OnUnrelatedMessage()
{
lock_mutex();
// do nothing
unlock_mutex();
}


This IS assuming you're using recursive mutexes. If you are not using recursive mutexes, the deadlock could happen even on the same thread.


Solution:
Find all mutex references in your project and make sure you're not wrapping any message sending routines inside the critical sections. The message loop is already assuring thread safety so you can send messages outside of critical sections.

A proper rewrite of the doSomething method would look like this:

void doSomething()
{
lock_mutex();
int x = someSensitiveArray[10]; // Only wrap data access inside critical sections, or calls that strictly follow the OOP hierarchy
unlock_mutex();

SendMessage(WM_SOMETHING, x);
}


I hope this helps,
Thanks

[rogerdpack]

As a note, I was able to reproduce this (windows XP, older computer). Basically full screen it, then alt-tab to any other program. VLC finishes playing the video in the background and then freezes, hard kill is the only way out.

[Razor512]

hopefully this is enough to prove that this is an actual issue with the program that warrants at least some attention.

[rogerdpack]

The good news is I wasn't able to reproduce it with 1.2.0 nightly, though I'm unable to test that hypothesis with windows 7 with the nightly, it fails to play anything
https://gist.github.com/1386636
You can try it.

Also it appears that
http://nightlies.videolan.org/build/win64/last
contains 32 bit binaries--I assume that's expected?
-r

[rogerdpack]

Here's a gdb thread apply all backtrace on a hung nightly build:
https://gist.github.com/1387611

[VLC_help]

Thanks. I will ticket this during weekend.

[VLC_help]

Did someone replicate this with VLC 1.2.0?

[rogerdpack]

unable to reproduce with 1.2.0
Able to reproduce quite readily on 1.1.11

[Jean-Baptiste Kempf]

Yes, should be fixed in 1.2.0. 1.1.x is dead, though.