vlc 2.6.6 crashs on gentoo with a segfault in libpthread-2.23.so while playing a dvb stream (h264 / AC3)caused by additional Gentoo-Patch (see: https://trac.videolan.org/vlc/ticket/18732 ) I have uploaded a test sample for you: https://mega.nz/#!VSREAJ7L!gos434sHGNkOiA6-zK-pR_F3oyquuIT00ZAry7QwdhM GDB Stacktrace (crash at 0:10min with selected audio channel german!) : gdb vlc GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc...Reading symbols from /usr/lib64/debug//usr/bin/vlc.debug...done. done. (gdb) run Starting program: /usr/bin/vlc [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 2.2.6 Umbrella (revision 2.2.6-0-g1aae78981c) [New Thread 0x7f1a82b6c700 (LWP 9375)] [New Thread 0x7f1a8dbc2700 (LWP 9376)] [New Thread 0x7f1a8882f700 (LWP 9377)] [0000000000605438] core libvlc: VLC wird mit dem Standard-Interface ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden. [New Thread 0x7f1a801e4700 (LWP 9379)] [00000000006fc578] qt4 interface error: Unable to load extensions module [New Thread 0x7f1a5ffff700 (LWP 9380)] [New Thread 0x7f1a5f7fe700 (LWP 9381)] [Thread 0x7f1a5f7fe700 (LWP 9381) exited] [Thread 0x7f1a5ffff700 (LWP 9380) exited] [New Thread 0x7f1a68211700 (LWP 9398)] [New Thread 0x7f1a68110700 (LWP 9399)] [New Thread 0x7f1a5effd700 (LWP 9400)] [Thread 0x7f1a5effd700 (LWP 9400) exited] [New Thread 0x7f1a5effd700 (LWP 9401)] [Thread 0x7f1a5effd700 (LWP 9401) exited] [Thread 0x7f1a68211700 (LWP 9398) exited] [New Thread 0x7f1a5f7fe700 (LWP 9402)] [New Thread 0x7f1a5ffff700 (LWP 9403)] [New Thread 0x7f1a43ad4700 (LWP 9404)] [New Thread 0x7f1a432d3700 (LWP 9405)] [New Thread 0x7f1a5effd700 (LWP 9406)] [New Thread 0x7f1a68211700 (LWP 9407)] libva info: VA-API version 0.39.4 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 [00007f1a54c86398] avcodec decoder: Using Intel i965 driver for Intel(R) Kabylake - 1.7.3 for hardware decoding. [h264 @ 0x7f1a54cc6da0] mmco: unref short failure [h264 @ 0x7f1a54cc6da0] mmco: unref short failure [h264 @ 0x7f1a54cc6da0] number of reference frames (0+4) exceeds max (3; probably corrupt input), discarding one [00007f1a58196838] freetype spu text error: failed to load font file Liberation Sans No accelerated IMDCT transform found [New Thread 0x7f1a389cf700 (LWP 9409)] [00007f1a58196838] freetype spu text error: failed to load font file Liberation Sans Thread 17 "vlc" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f1a68211700 (LWP 9407)] __GI___pthread_mutex_lock (mutex=mutex@entry=0xb0) at ../nptl/pthread_mutex_lock.c:67 67 unsigned int type = PTHREAD_MUTEX_TYPE_ELISION (mutex); (gdb) bt #0 __GI___pthread_mutex_lock (mutex=mutex@entry=0xb0) at ../nptl/pthread_mutex_lock.c:67 #1 0x00007f1a8ce52f19 in vlc_mutex_lock (p_mutex=p_mutex@entry=0xb0) at posix/thread.c:256 #2 0x00007f1a8ce30bdc in aout_OutputLock (aout=aout@entry=0x0) at audio_output/output.c:543 #3 0x00007f1a8ce2e139 in aout_DecDelete (aout=0x0) at audio_output/dec.c:116 #4 0x00007f1a8cdffb22 in aout_update_format (p_dec=0x7f1a54d1ed78) at input/decoder.c:1972 #5 0x00007f1a8ce00c19 in decoder_UpdateAudioFormat (dec=0x7f1a54d1ed78, dec@entry=0x7f1a48002360) at ../include/vlc_codec.h:214 #6 decoder_NewAudioBuffer (dec=dec@entry=0x7f1a54d1ed78, samples=1536) at input/decoder.c:187 #7 0x00007f1a4f7efd1a in GetAoutBuffer (p_dec=0x7f1a54d1ed78) at codec/a52.c:385 #8 GetOutBuffer (pp_out_buffer=<synthetic pointer>, p_dec=0x7f1a54d1ed78) at codec/a52.c:370 #9 DecodeBlock (p_dec=0x7f1a54d1ed78, pp_block=0x7f1a68210db8) at codec/a52.c:295 #10 0x00007f1a8ce0083f in DecoderDecodeAudio (p_dec=p_dec@entry=0x7f1a54d1ed78, p_block=p_block@entry=0x7f1a54dabca0) at input/decoder.c:1222 #11 0x00007f1a8ce01e8b in DecoderProcessAudio (b_flush=false, p_block=0x7f1a54dabca0, p_dec=0x7f1a54d1ed78) at input/decoder.c:1684 #12 DecoderProcess (p_block=<optimized out>, p_dec=0x7f1a54d1ed78) at input/decoder.c:1811 #13 DecoderThread (p_data=0x7f1a54d1ed78) at input/decoder.c:909 #14 0x00007f1a8d63e3e4 in start_thread (arg=0x7f1a68211700) at pthread_create.c:333 #15 0x00007f1a8d181a9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb)
I recompilled the vlc-2.2.6. without the requestet patches from #594126 # Bug #594126 #"${FILESDIR}"/${PN}-2.2.4-decoder-lock-scope.patch #"${FILESDIR}"/${PN}-2.2.4-alsa-large-buffers.patch Now vlc is working for me again without any issues. I would suggest to fix or remove this patches because they break the vlc for ohter people.
You know what, I've removed the patches and can instantly reproduce bug 594126 - vlc does not crash but the stream is unusable. There does not seem to be a good solution here.
(In reply to dekbertu from comment #1) > I recompilled the vlc-2.2.6. without the requestet patches from #594126 > > # Bug #594126 > #"${FILESDIR}"/${PN}-2.2.4-decoder-lock-scope.patch > #"${FILESDIR}"/${PN}-2.2.4-alsa-large-buffers.patch > > Now vlc is working for me again without any issues. > I would suggest to fix or remove this patches because they break the vlc for > ohter people. Can you try reverting one patch at a time?
It also crashes with only 2.2.4-decoder-lock-scope.patch applied.
(In reply to Joakim Tjernlund from comment #3) > (In reply to dekbertu from comment #1) > > I recompilled the vlc-2.2.6. without the requestet patches from #594126 > > > > # Bug #594126 > > #"${FILESDIR}"/${PN}-2.2.4-decoder-lock-scope.patch > > #"${FILESDIR}"/${PN}-2.2.4-alsa-large-buffers.patch > > > > Now vlc is working for me again without any issues. > > I would suggest to fix or remove this patches because they break the vlc for > > ohter people. > > Can you try reverting one patch at a time? The decoder-lock-scope.patch is the one who makes the vlc unusable for me. But i dont think its a good idea to patch vlc of distribution base you should ask the videolan guys if it possible to fix the issues in the maintained tree. The guy in the debian thread also says: "At least, all the patches for VLC 2.2 that I´ve seen proposed are all known broken. That is to say that they do fix the symptoms, but they introduce even worse problems that _will_ break VLC for other people."
(In reply to dekbertu from comment #5) > But i dont think its a good idea to patch vlc of distribution base you > should ask the videolan guys if it possible to fix the issues in the > maintained tree. Yes, downstream patching is to be avoided where possible - however without it we a) could not build latest vlc on current stable GCC b) could not build latest vlc against stable Qt5 c) could not build latest vlc against stable ffmpeg I would much prefer to be able to package a release that does not need patches. Upstream is well aware of the bug since they fixed it themselves but choose not to fix it in stable branch. And they keep to not release 3.0. There is nothing I can add to that. Thanks to Joakim in bug 594126 we can fix the broken patch and keep shipping it. 2.2.6-r2 added in git commit eff19da8e22050be19180b57c3df1984db7bd23f - go forth and test.
(In reply to Andreas Sturmlechner from comment #6) > (In reply to dekbertu from comment #5) > > But i dont think its a good idea to patch vlc of distribution base you > > should ask the videolan guys if it possible to fix the issues in the > > maintained tree. > Yes, downstream patching is to be avoided where possible - however without > it we > a) could not build latest vlc on current stable GCC > b) could not build latest vlc against stable Qt5 > c) could not build latest vlc against stable ffmpeg > > I would much prefer to be able to package a release that does not need > patches. Upstream is well aware of the bug since they fixed it themselves > but choose not to fix it in stable branch. And they keep to not release 3.0. I suspect upstream VLC (to be 3.0) is broken too. I think this patch originated from there.
That is something we can easily test via vlc-9999, and a fresh build I just did neither stutters nor segfaults with your test sample.
(In reply to Andreas Sturmlechner from comment #8) > That is something we can easily test via vlc-9999, and a fresh build I just > did neither stutters nor segfaults with your test sample. To make sure, look in the same file as the patch touched.
http://git.videolan.org/gitweb.cgi/vlc.git/?p=vlc.git;a=commitdiff;h=6ae2905ef7fbc7de3a3a4a1bdf8ad6df46ce570a --- a/src/input/decoder.c +++ b/src/input/decoder.c @@ -265,11 +265,10 @@ static int aout_update_format( decoder_t *p_dec ) /* Parameters changed, restart the aout */ vlc_mutex_lock( &p_owner->lock ); - - aout_DecDelete( p_owner->p_aout ); p_owner->p_aout = NULL; - vlc_mutex_unlock( &p_owner->lock ); + aout_DecDelete( p_owner->p_aout ); + input_resource_PutAout( p_owner->p_resource, p_aout ); Same bug but in another function.
(In reply to Joakim Tjernlund from comment #10) > http://git.videolan.org/gitweb.cgi/vlc.git/?p=vlc.git;a=commitdiff; > h=6ae2905ef7fbc7de3a3a4a1bdf8ad6df46ce570a > > --- a/src/input/decoder.c > +++ b/src/input/decoder.c > @@ -265,11 +265,10 @@ static int aout_update_format( decoder_t *p_dec ) > > /* Parameters changed, restart the aout */ > vlc_mutex_lock( &p_owner->lock ); > - > - aout_DecDelete( p_owner->p_aout ); > p_owner->p_aout = NULL; > - > vlc_mutex_unlock( &p_owner->lock ); > + aout_DecDelete( p_owner->p_aout ); > + > input_resource_PutAout( p_owner->p_resource, p_aout ); > > Same bug but in another function. I suspect aout_DecDelete( p_owner->p_aout ) should be aout_DecDelete( p_aout ) as the func. holds a local ptr for p_owner->p_aout. Maybe our local patch could be modified to do the same?
I sent a mail to the author, Rémi Denis-Courmont <remi@remlab.net>. With any luck he will look into it.
(In reply to Joakim Tjernlund from comment #11) > (In reply to Joakim Tjernlund from comment #10) > > http://git.videolan.org/gitweb.cgi/vlc.git/?p=vlc.git;a=commitdiff; > > h=6ae2905ef7fbc7de3a3a4a1bdf8ad6df46ce570a > > > > --- a/src/input/decoder.c > > +++ b/src/input/decoder.c > > @@ -265,11 +265,10 @@ static int aout_update_format( decoder_t *p_dec ) > > > > /* Parameters changed, restart the aout */ > > vlc_mutex_lock( &p_owner->lock ); > > - > > - aout_DecDelete( p_owner->p_aout ); > > p_owner->p_aout = NULL; > > - > > vlc_mutex_unlock( &p_owner->lock ); > > + aout_DecDelete( p_owner->p_aout ); > > + > > input_resource_PutAout( p_owner->p_resource, p_aout ); > > > > Same bug but in another function. > > I suspect aout_DecDelete( p_owner->p_aout ) should be > aout_DecDelete( p_aout ) as the func. holds a local ptr for p_owner->p_aout. > Maybe our local patch could be modified to do the same? Yes, that seems to be a typo, aout_DecDelete( p_aout ) is correct.
Joakim Tjernlund and Andreas Sturmlechner thank you very much for your efforts. I'm very pleased with the latest vlc-2.2.6-r2 build and hope it works for all. :-)
All praise goes to Joakim - please also report back upstream, so they are not kept in the wrong believe that we do not care about vlc.
Hey, Quick intro, I'm a VLC developer, and more or less responsible for backporting to the 2.2.x branch nowadays. I just looked at the patch, and I'm afraid it isn't thread-safe without the previous patch (5b2de76965ee8b1ab5e3257f8b6d71bbb4e9e3f9). However, those commit are a bit too dangerous for a stable branch backport in my opinion. Hopefully the situation will solve itself when we release 3.0 (which is very late, but we're very close from a RC) That being said, sorry about the bit of drama on the VLC ticket... We don't want to ignore Gentoo users at all, and we don't think you don't care about VLC. Please keep sending us your patches! Cheers,
Reopening as this issue is not fixed for stable users.
You could have filed a stabilisation request then. But let's target 2.2.8, it doesn't have a big delta over 2.2.6.
