VLC crashes when u try to run multiple instances of it

[Rémi Denis-Courmont]

As you say, I am on the VLC team, not the Fontconfig team of the ALSA team.

[ghazzalyahmad]

Apologies for my mistake, but how can i get in touch with both teams (I am quite new to this forum)...

[sherington]

The isPlaying() -> yield() hack.. caused me more problems. it also caused the application to crash.

Hmm.. that works for me.

Try using this experimental class (it has nicer synchronisation than the yield hack). This is tested and works for me.

http://vlcj.googlecode.com/svn/trunk/vl ... Latch.java

The Javadoc shows how to use it.

It's not ideal but it might help you.

[Rémi Denis-Courmont]

I don't see cany reliable way to avoid any race other than using different process for each media player.

ALSA is hosted at http://www.alsa-projects.org/ but unless you have a strong case for a bug in alsalib, or better a patch, I would not expect much. I don't know about Fontconfig.

[ghazzalyahmad]

Hi everyone,

Just wanna give an update:
@sherington: I tired to using the experimental class, it worked but not always.

So i decided to compile vlc without the font config using (--disable-fontconfig) and using (--no-xlib) and (--no-audio) and (--no-osd).. The result that it doesn't crash as often anymore... actually i write an application the calls stop and play several time running in multiple instances, and after calling stop and play 1351 times, it crashed. Don't know really why since i disabled all the unsafe threads, but it is way better than before.

There is was one thing though, that maybe some-one can tell me what i need to do to avoid such thing is that when i tried starting the application after it crashed i got this in the output: freetype spu text error: Failed to get fontfile. maybe it is nothing..

I hope this would be helpful to anyone and thanks alot to everyone who participated in it.

[ghazzalyahmad]

Hi everyone,

Apparently i am bit mistaken.. the application still crashes it is way less than before, but if i open and start the application lets say 3 times, one of the time it crashes on start-up.. is there other functionalities that i need to disable that are not thread safe?

[Rémi Denis-Courmont]

The backtrace will tell you what.

[ghazzalyahmad]

Hi Remi,

I know that this could be a stupid question, but how can i activate/see the backtrace?

[Jean-Baptiste Kempf]

gdb

[ghazzalyahmad]

apologies but what is gdb?

[WippelDa]

The GNU Debugger

http://www.gnu.org/software/gdb/

[ghazzalyahmad]

Hi everyone,

Just a quick update. I was able to compile VLC without the fontconfig functionality and now i am able to play the live stream with the following options "--no-xlib" and "--no-aduio". This seemed to get ride of the crashing problem that i was facing earlier. I do still get some crashing happening after calling stop and play for large number of times, but for the reason behind this i am not sure yet why, could be a hardware problem (due to the fact that the machine gets restarted). If i get somewhere with it, i will give an update.

Again thanks a million for everyone who participated and helped out.

[rmurphyxxx]

We are experiencing same problem on a similar application (9 video screens), but using C++ code directly using libvlc.dll. Initially noticed the problem with a C# wrapper, so developed a simple (Windows) C++ app that dynamically loads the dll. Tried a whole host of solutions including delays, loading multiple instances of dll, every conceivable combination of releasing media, maintaining media, stopping player, checking if it is stopped, using will_play, using is_playing, etc in attempts to verify the health of the player before starting a new stream. All to no avail - still periodically crashes. Using 1.1.4 version. Tried with C++ Builder (VCL) container, Windows API windows, and C# frames as the containers/windows for the videos to be dispalyed on. Nothing has worked and no way to trap the crashes in order to recover gracefully.

[Rémi Denis-Courmont]

There may be a deadlock somewhere. But without a full and threaded stack trace (or a test case easy enough to reproduce), nobody will ever try to fix it for you.

[johnsheng]

I have met same situation.
I have develop a video surveillance player using libvlc(1.0.0) lib and dll , the player can setup 9 instances in one application , is used to display 9 rtsp videos .
when I start 9 instance to display 9videos in succession, after a while , I find that a video freeze , always display last video picture . I grab rtsp and rtp packages by wireshark , it is found that the corresponseding rtp connection disconnected (it is hard to understand that server send two rtps packages over tcp to client ,however client do not send ack of tcp to server), the input thread of the freeze player is stopped , but the video output thread is still running , always display the last video picture . what cause the problem? lately , I use vlc-1.1.0 and 0.9.9 to debug , players freeze one by one early or late . how should input thread tell other thread that no data reaches after the input thread get to know disconnection of net through live555? by events management ? My developing friend also develop a player with activex of vlc , also 9 instance , but his player can stablly display , no instance freeze .
there are other issues in libvlc . some times when no data reach clent , live555 of vlc can not detect this situation .
anybody can give me some suggestion? I have spend 2 weeks to debug libvlc , but no make progress , desperate .
thanks

[Jean-Baptiste Kempf]

Even with 1.1.5 ?

[Beardless2]

Hi JB,

I also get this behaviour with 4+ instances with Win32 with 1.1.5, although the app has to be compiled for it to trigger, when running the app from debug mode in my Delphi IDE it never happens (i presume the IDE slows down the calls to play just enough so the deadlock doesn't occur)

Chris

[johnsheng]

about the above problem , I have fine a bug:
problem: launch a rtsp player(develop with libvlc) , a short time later , when no net data reach player , the live demux of player can exit . you can get the debug info of "msg_Dbg( p_input, "EOF reached" )" in MainLoopDemux when exit , but the thread "RunThread" in video_output.c dose not stop and exit after input thread is dead , the thread always display last picture .
To find cause , we can compare the two kinds of call method , one is vlc.exe call ,the other is our program call to libvlc .
one: vlc.exe call like as :
/* Initialize libvlc */
libvlc_instance_t *vlc;
vlc = libvlc_new (argc - 1, (const char **)argv + 1, &ex);
if (vlc != NULL)
{
libvlc_add_intf (vlc, "globalhotkeys , none", &ex);
libvlc_add_intf (vlc, NULL, &ex);
libvlc_playlist_play (vlc, -1, 0, NULL, &dummy);
libvlc_wait (vlc);
libvlc_release (vlc);
}
url is send to libvlc_new as a parameter , the call of libvlc_playlist_play is very importment , the two sequences are
call sequence 1: libvlc_playlist_play -> playlist_Control(.. PLAYLIST_PLAY..)->pl_priv(p_playlist)->request.b_request = true
call sequence 2: libvlc_new->...>libvlc_InternalInit-> playlist_Activate->vlc_clone( ..Thread..)->LoopRequest( if( i_status == PLAYLIST_STOPPED || !vlc_object_alive( p_playlist ) ) )->
PlayItem->var_AddCallback(.. "intf-event", InputEvent.. );
the function InputEvent is very importment . when EOF reach , the thread of "Run" in input.c call input_SendEventDead( p_input ) , at last input_SendEventDead will call InputEvent , then InputEvent set a
signal (vlc_cond_signal( &pl_priv(p_playlist)->signal )) , later the thread of "thread" in thread.c get to know "vlc_cond_wait( &p_sys->signal,
&p_sys->lock )", call 2 will receive the signal , in this way all thread exit .

the other :
p_media = libvlc_media_new( m_pVLCInstance , psz_name, &m_VLCex );
libvlc_media_player_set_media( m_pMediaPlayer , p_media, &m_VLCex );
libvlc_media_player_play( m_pMediaPlayer , &m_VLCex );
libvlc_media_player_set_drawable()
libvlc_media_player_set_media (m_pMediaPlayer, m_pMedia, &m_VLCex);
libvlc_media_player_play( m_pMediaPlayer , &m_VLCex );
in this call method , player register input_event_changed in libvlc_media_player_play(src:var_AddCallback( p_input_thread, "intf-event", input_event_changed, p_mi )) as a callback , instead of InputEvent . as a result the thread of "Run" in input.c can not call function of InputEvent to tell video output thread when EOF reach.
hope that somebody can give some suggestion to fix bug .
thank you .

[jwlangston21]

This bug still exists in 1.1.11.

I've come to the same problem as the previous users: when multiple back-to-back calls to "libvlc_media_player_play" occur, the program crashes in Visual Studio 2010 debugger with either an access violation or a heap corruption. The Visual Studio 2010 Pro IDE doesn't catch anything of note in the call stack. And since I'm using the DLLs/LIBs, I don't know where it crashes.

The software in development is a VC++ MFC SDI application with 3 CStatics'. The CStatics' hwnds are used for "libvlc_media_player_set_hwnd". I have tried multiple "libvlc_instance_t" instances, and a single shared instance, but the problem still occurs. Perhaps they could be run in separate processes, but this makes the development much more difficult.

The system is a top-end consumer-grade Windows 7 PC. The libvlc and libvlccore .libs were generated as prescribed here: http://wiki.videolan.org/GenerateLibFromDll

Any help revisiting this problem would be greatly appreciated!