The VideoLAN Forums

Hello everyone,

I am currently writing an application where it can display up to 12 monitors of live video streams. The problem that I am currently facing that when I start/stop the application sometimes I get a java fatal error. After searching about the problem, it seems that making multiple calls in quick succession to libvlc_media_player_play causes a crash, according to the VLCJ website: http://code.google.com/p/vlcj/wiki/Mult ... rInstances. There is written the following:
"The VLCJ bindings are generally stable and hard crashes in the Java Virtual Machine due to native library failures usually don't occur.
However, when using multiple video player instances the chance for instability and hard crashes increases.
..., when there are up to three video player instances everything is still stable.
However, with more than three video player instances there is a chance of a fatal native library crash, apparently due to a race condition during start-up. If the race condition does not materialise then all instances will play videos correctly.
These crashes occur in native libraries and there's not much that VLCJ can do about it.
The main cause of failure seems to be as a result of making multiple calls in quick succession to libvlc_media_player_play. It is possible to workaround this problem (to some degree) by staggering the play calls (e.g. with a one second delay between calls)."

I did try the workaround (showed improvement, but still it is no guarantee that it won't crash), however having 1 second delay between the calls is a bit too much and it doesn't always work.

I am wondering if this is a known problem and the VLC-team will attempt to fix it in VLC 1.1.2?

And is there a command-line parameter that can be used to avoid this problem?

Thanks in advance for your help..

Gr.
Ahmed

From the point of view of the Java bindings, the reason I said I think there's a race is that I can see no pattern in the failures - sometimes it works just fine for me, sometimes it crashes. Same code, same video files. Increasing the number of instances seems to make it more likely to crash, but even then it doesn't always crash. I have very little experience in debugging native libraries when JVM crashes occur so I don't really know what I can do about it from the Java side.

I'm not saying vlc is causing the crash, I'm saying I don't know what's causing the crash.

I am wondering if this is a known problem and the VLC-team will attempt to fix it in VLC 1.1.2?

There were a number of issues in LibVLC 1.0.
There are no known (crash) issues in LibVLC 1.1.1, and only accept bug reports concerning the native API, since we do not maintain the bindings.

I post here in the hope that anyone has any ideas, not because I blame vlc for errors.

What I see from valgrind (I'm very new to that tool) when the error we're discussing occurs (against 1.1.1) is this: The top google result for me refers to this post but I have no idea if it's relevant to vlc: http://sourceware.org/ml/libc-help/2008 ... 00072.html

Unfortunately from the Java side I have no idea what to do about this.

Looks like a bug in valgrind. What does gdb say?

Looks like a bug in valgrind. What does gdb say?

I've posted here backtraces and thread lists for the three different types of failures I've seen when using gdb.

I see different types of failures and which particular failure occurs at any particular time is unpredictable.

I can't be sure any of these back-traces refers to the valgrind error above, but all of these errors do occur when I use multiple media player instances (without staggering the libvlc_media_player_play calls).

I pulled the 1.1 maintenance branch and did a full build configured with --enable-debug and --disable-optimizations.

This is the version and changeset I am running these tests against:

* 1.1.2-git The Luggage
* 1.1.1-22-gc7cc7c2

This usually happens first...
Followed by this (after restarting the program being debugged)...
I see mostly these ones - which maybe indicates a Java VM issue? Obviously the missing parts of the trace don't help.
I hope this is what you're asking for, I'm not familiar much with these tools.

I'm happy to run more tests and provide more info if you think this is worth pursuing.

The last one is most likely because your process fails to call XInitThreads() before the first use of Xlib. I don't know about the first ones, but they're deep within FontConfig.

The last one is most likely because your process fails to call XInitThreads() before the first use of Xlib. I don't know about the first ones, but they're deep within FontConfig.

Thanks for looking over that.

I don't think I can do anything about it in the Java bindings - if like you say something is failing to call XInitThreads() at the right time, then that is something that is presumably hidden deep inside the Java VM. We never deal with Xlib directly at all in Java applications.

So I guess to go back to the OP, there's nothing that can be done. If it's a JVM bug, complain to Oracle or the OpenJDK people.

It's not necessarily a bug in the JVM. If AWT only uses Xlib from a single (native) thread per process, not calling XInitThreads() is perfectly legitimate. I don't know its internals, but I guess that is the case.

Then you're simply not allowed to use Xlib from any other (native) thread than the one using AWT. That implies LibVLC cannot use Xlib; the "--no-xlib" was created for that particular case. Unfortunately, it means the PulseAudio audio outputs, and the OpenGL/GLX, SDL and ASCII Art video outputs will be disabled.

It's not necessarily a bug in the JVM. If AWT only uses Xlib from a single (native) thread per process, not calling XInitThreads() is perfectly legitimate. I don't know its internals, but I guess that is the case.

That's interesting, thanks.

I'd like to hear from the OP if this simplistic workaround resolves the issue for him/her. This works reliably for me, and it gives hope that with further work I can encapsulate a proper workaround in the Java bindings (basically to make sure calls to libvlc_media_player_play are serialised and wait for the player to start between calls). Maybe using events would be better than the yield loop, and there are obvious issues to address like what if isPlaying never returns true. I'll do some more work on this.

--no-xlib is already used by the Mozilla plugin for the same reason.

We have spent a lot of time making sure libvlc proper is reentrant. I would not recommend going the hack route.

--no-xlib is already used by the Mozilla plugin for the same reason.

We have spent a lot of time making sure libvlc proper is reentrant. I would not recommend going the hack route.

Hmm... ok. I guess for now I will leave it up the client application to decide if they want to try disabling xlib or try doing the hack approach themselves, rather than hacking inside the bindings.

It only affects users who need to create multiple instances so I suspect most users probably won't care.

Thanks again for the discussion and pointers on this.

That's not true. The probably that the crash increases dramatically with the number of instances, due to the application of the birthday paradox to race conditions. But it can happen even with a single instance. In fact, it is very likely to cause a crash when AWT cleans up after itself, regardless of the number of instances.

That's not true. The probably that the crash increases dramatically with the number of instances, due to the application of the birthday paradox to race conditions. But it can happen even with a single instance. In fact, it is very likely to cause a crash when AWT cleans up after itself, regardless of the number of instances.

OK, I accept what you're saying and I will try and resolve it because obviously I don't want to cause crashes, but at this moment I don't know what I can realistically do about it inside the bindings.

At the bindings level, the only solution is to always pass --no-xlib.

At the bindings level, the only solution is to always pass --no-xlib.

Yes that does indeed get rid of one of the types of crash.

I'm still doing a lot of tests and work on this because now that I have most of the functionality I want exposed in the bindings I want to focus on the reliability and eliminating crashes.

So...

Something else is still going wrong because I still see random font config crashes (as described earlier), and now I see new random other crashes.

Here's a flavour of the new errors (mostly the JVM crashes soon afterwards):
(I made sure I compiled and installed the latest alsa.)

Here's some more random anecdotal observations...

If the JVM does not crash immediately, I sometimes see some of the media player instances stop playing video after a short while.

With "--no-audio" I see only the fontconfig errors causing VM crashes.

Sometimes, but rarely, the multi-instance test I have starts and runs perfectly no matter what args I pass to libvlc.

If I do the isRunning hack described earlier, it works 100% - I know that's not the right answer, I just say it for something to compare against.

The same behaviour happens whether I embed the output or leave it for libvlc to open up it's own video windows.

I must say, I don't know if fontconfig is internally thread safe. But it might also be that the process ran out of memory (I expect fontconfig/freetype do large-ish allocations).

The ALSA one looks odd, especially out of the blue.

The ALSA one looks odd, especially out of the blue.

Sorry for any confusion, those errors weren't all in sequence from the same session.

So next I did a build of vlc with --disable-font-config. If I use that build in conjunction with --no-xlib libvlc args then, as you'd probably expect, I get much less JVM crashes, but still get some.

I also still randomly get ALSA warnings and other errors dumped to the console, here's the latest example: The only post I could find regarding thread-safetiness of fontconfig was some release notes here http://qt.nokia.com/developer/changes/changes-4.5.2/ which stated "[241361] Prevented asynchronous access to non-thread safe libfontconfig API".

I do feel like I'm pushing the problem around from one sub-system to the next!

Looks like ALSA is not thread-safe then. Starting only one media at a time only reduces the chances of hitting the problem though.

Hi everyone,

First of all, thanks a million for the discussion and great insight on this problem.

I tried the --no-xlib and it works, it doesn't crash as often, however it still does sometimes, but not as bas as before. Unfortunately I am not very familiar on how to capture the error and show what the problem is. I don't even get any logs about the error. If someone can tell me how I would capture it, I would love to try and post it. However, i can also provide a working sample of the application.

Again thanks for the support...

If someone can tell me how I would capture it, I would love to try and post it. However, i can also provide a working sample of the application.

I don't think you're going to be able to capture anything we don't already know about. FontConfig is seemingly not thread-safe, ALSA is seemingly not thread-safe. A single-threaded Java application calling multiple libvlc_play_media in quick succession will lead to crashes.

As of right now, I would do the isPlaying() -> yield() hack as previously described in this thread. Whilst far from ideal, it's all you can do for now if --no-xlib etc is not working 100% for you.

The isPlaying() -> yield() hack.. caused me more problems. it also caused the application to crash. Is there a way (like the --no-xlib) to also disable the FontConfig and ALSA..?

The only way to disable fontconfig is to compile VLC without it (--disable-fontconfig). This is likely to break all OSD functionality.

To disable ALSA, you need to force another audio output, or to compile VLC without ALSA, and without SDL_audio (which probably wraps ALSA). Since --no-xlib disables PulseAudio, that leaves no option but OSS. OSS does typically not support multiple clients, and there is most probably already one (PulseAudio daemon, another VLC instance, the desktop environment, etc), so you can basically forget audio.

Thanks for the quick reply.

Seeing that your one of the VLC team, is there a way in which these functionalities would be thread safe any time soon, in one of the coming releases?