Bug#831529: Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-25 Thread Faidon Liambotis 
reopen 831529
reassign 831529 libavcodec57 7:3.1.1-2
forcemerge 831909 831529
thanks

Hi,

On Sun, Jul 24, 2016 at 02:53:57PM +0200, Sebastian Ramacher wrote:
> On 2016-07-24 14:19:36, Sebastian Ramacher wrote:
> > On 2016-07-22 13:27:09, Faidon Liambotis wrote:
> > > On Fri, Jul 22, 2016 at 10:21:05AM +0200, Sebastian Ramacher wrote:
> > > > Unfortunately I am unable to reproduce the issue. Since there are some 
> > > > accounts
> > > > of random crashes when building ffmpeg with tree vectorization enabled, 
> > > > I've
> > > > uploaded 7:3.1.1-3 with vectorization disabled. Could you please check 
> > > > if the
> > > > issue disappears with -3?
> > > 
> > > I upgraded all ffmpeg packages to 7:3.1.1-3 but I'm still experiencing
> > > crashes.

I followed what the reporter of #831529 suggested: I first tried to "apt
install --reinstall gstreamer1.0-libav", which had no effect. I then
upgraded to the version from experimental, ran gst-launch again, then
downgraded to the version from unstable, which also seem to not crash
now(!).

I'm not very familiar with the gstreamer/libav/libva stack and thus
would like some help to get to the bottom of this. Frankly, I still
don't understand why x264 and VA-API is even at play here, when it's
just a pipeline of parsing a wav into a fakesink.

Regardless, I'm keeping this as an ffmpeg bug though (and at grave), as
the crashes started with the recent ffmpeg upgrade and the backtraces
seem to suggest that the abort() is coming from ffmpeg.

Thanks,
Faidon

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-24 Thread Faidon Liambotis 
On Sun, Jul 24, 2016 at 02:53:57PM +0200, Sebastian Ramacher wrote:
> On 2016-07-24 14:19:36, Sebastian Ramacher wrote:
> > Thank you for the info. Could you please let us know the version of libva1 
> > and
> > i965-va-driver that you have installed?
> 
> … and the versions of all other libva1-* packages.

All of the above[1] are at 1.7.1-1. I run a pretty standard up-to-date
testing -- with the exception of all ffmpeg packages from sid, as
previously requested.

Faidon

1:
ii  i965-va-driver:amd64 1.7.1-1 amd64 VAAPI driver for Intel G45 & HD Graphics 
fami
ii  libva-drm1:amd64 1.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
DRM 
ii  libva-glx1:amd64 1.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
GLX 
ii  libva-wayland1:amd64 1.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
Wayl
ii  libva-x11-1:amd641.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
X11 
ii  libva1:amd64 1.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
runt

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-24 Thread Sebastian Ramacher 
On 2016-07-24 14:19:36, Sebastian Ramacher wrote:
> Hi
> 
> On 2016-07-22 13:27:09, Faidon Liambotis wrote:
> > On Fri, Jul 22, 2016 at 10:21:05AM +0200, Sebastian Ramacher wrote:
> > > Unfortunately I am unable to reproduce the issue. Since there are some 
> > > accounts
> > > of random crashes when building ffmpeg with tree vectorization enabled, 
> > > I've
> > > uploaded 7:3.1.1-3 with vectorization disabled. Could you please check if 
> > > the
> > > issue disappears with -3?
> > 
> > I upgraded all ffmpeg packages to 7:3.1.1-3 but I'm still experiencing
> > crashes.
> > 
> > I then installed libavcodec57-dbgsym, libgstreamer1.0-0-dbg,
> > gstreamer1.0-libav-dbg and gstreamer1.0-plugins-good-dbg. The full
> > backtrace is below. The "codec = " seems
> > relevant, since this is on an Intel Broadwell, which may not be the case
> > for you. This looks a lot like #831529, doesn't it?
> > 
> > I still don't exactly understand how H.264/VA-API are related when playing
> > just a .wav file, though... This was with the same gstreamer pipeline,
> >   gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  !
> >   wavparse ! audioconvert ! fakesink
> > 
> > 
> > #0  0x76fc01c8 in __GI_raise (sig=sig@entry=6)
> > at ../sysdeps/unix/sysv/linux/raise.c:54
> > #1  0x76fc164a in __GI_abort () at abort.c:89
> > #2  0x7fffeda6260b in init_context_defaults (s=s@entry=0x70095720, 
> > codec=codec@entry=0x7fffee3a8900 )
> > at src/libavcodec/options.c:142
> > #3  0x7fffeda626d6 in avcodec_alloc_context3 (codec=0x7fffee3a8900 
> > ) at src/libavcodec/options.c:163
> > #4  0x7fffef360540 in gst_ffmpeg_cfg_install_property 
> > (klass=0x70095200, base=8) at gstavcfg.c:732
> > #5  0x7fffef356e53 in gst_ffmpegvidenc_class_init (klass=0x70095200)
> > at gstavvidenc.c:225
> > #6  0x7788c22d in g_type_class_ref (pclass=0x70094690, 
> > node=0x70094500) at 
> > /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241
> > #7  0x7788c22d in g_type_class_ref (type=type@entry=140737220527360)
> > at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956
> > #8  0x77b09da4 in gst_element_register 
> > (plugin=plugin@entry=0x69bbf0 [GstPlugin], name=name@entry=0x7006d110 
> > "avenc_h264_vaapi", rank=rank@entry=128, type=type@entry=140737220527360) 
> > at gstelementfactory.c:243
> > #9  0x7fffef3575b3 in gst_ffmpegvidenc_register 
> > (plugin=plugin@entry=0x69bbf0 [GstPlugin]) at gstavvidenc.c:1009
> > #10 0x7fffef349e20 in plugin_init (plugin=0x69bbf0 [GstPlugin])
> > at gstav.c:158
> > #11 0x77b2b537 in gst_plugin_register_func (plugin=0x69bbf0 
> > [GstPlugin], desc=0x7fffef578180 , user_data=0x0) at 
> > gstplugin.c:523
> > #12 0x77b2d425 in _priv_gst_plugin_load_file_for_registry 
> > (filename=0x6c2e20 
> > "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so", registry=0x61c150 
> > [GstRegistry], registry@entry=0x0, error=error@entry=0x74de7bf0)
> > at gstplugin.c:826
> > #13 0x77b2dcea in gst_plugin_load_file (filename=, 
> > error=error@entry=0x74de7bf0) at gstplugin.c:680
> > #14 0x77b2e12c in gst_plugin_load_by_name (name=0x6c218d "libav")
> > at gstplugin.c:1265
> > #15 0x77b2ea8d in gst_plugin_feature_load 
> > (feature=feature@entry=0x6e58a0 [GstTypeFindFactory]) at 
> > gstpluginfeature.c:111
> > #16 0x77b547e3 in gst_type_find_factory_call_function 
> > (factory=0x6e58a0 [GstTypeFindFactory], find=0x74de7c90) at 
> > gsttypefindfactory.c:210
> > #17 0x75d89421 in gst_type_find_helper_for_data 
> > (obj=obj@entry=0x812070 [GstWavParse], data=, 
> > size=, prob=prob@entry=0x74de7db4) at 
> > gsttypefindhelper.c:535
> > #18 0x75d895a4 in gst_type_find_helper_for_buffer 
> > (obj=obj@entry=0x812070 [GstWavParse], buf=buf@entry=0x70003450, 
> > prob=prob@entry=0x74de7db4)
> > at gsttypefindhelper.c:591
> > #19 0x75b3546a in gst_wavparse_add_src_pad (wav=wav@entry=0x812070 
> > [GstWavParse], buf=0x70003450) at gstwavparse.c:1908
> > #20 0x75b35b47 in gst_wavparse_stream_data (wav=wav@entry=0x812070 
> > [GstWavParse]) at gstwavparse.c:2061
> > #21 0x75b3bbb1 in gst_wavparse_loop (pad=0x8042a0 [GstPad])
> > at gstwavparse.c:2202
> > #22 0x77b4fe71 in gst_task_func (task=0x81c050 [GstTask])
> > at gsttask.c:332
> > #23 0x775bc55e in g_thread_pool_thread_proxy (data=) 
> > at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthreadpool.c:307
> > #24 0x775bbbc5 in g_thread_proxy (data=0x81a800) at 
> > /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthread.c:780
> > #25 0x77335464 in start_thread (arg=0x74de8700) at 
> > pthread_create.c:333
> > #26 0x7707430d in clone () at 
> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> 
> Thank you for the info. Could you please let us know the version of libva1 and
> i965-va-driver that

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-24 Thread Sebastian Ramacher 
Hi

On 2016-07-22 13:27:09, Faidon Liambotis wrote:
> On Fri, Jul 22, 2016 at 10:21:05AM +0200, Sebastian Ramacher wrote:
> > Unfortunately I am unable to reproduce the issue. Since there are some 
> > accounts
> > of random crashes when building ffmpeg with tree vectorization enabled, I've
> > uploaded 7:3.1.1-3 with vectorization disabled. Could you please check if 
> > the
> > issue disappears with -3?
> 
> I upgraded all ffmpeg packages to 7:3.1.1-3 but I'm still experiencing
> crashes.
> 
> I then installed libavcodec57-dbgsym, libgstreamer1.0-0-dbg,
> gstreamer1.0-libav-dbg and gstreamer1.0-plugins-good-dbg. The full
> backtrace is below. The "codec = " seems
> relevant, since this is on an Intel Broadwell, which may not be the case
> for you. This looks a lot like #831529, doesn't it?
> 
> I still don't exactly understand how H.264/VA-API are related when playing
> just a .wav file, though... This was with the same gstreamer pipeline,
>   gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  !
>   wavparse ! audioconvert ! fakesink
> 
> 
> #0  0x76fc01c8 in __GI_raise (sig=sig@entry=6)
> at ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76fc164a in __GI_abort () at abort.c:89
> #2  0x7fffeda6260b in init_context_defaults (s=s@entry=0x70095720, 
> codec=codec@entry=0x7fffee3a8900 )
> at src/libavcodec/options.c:142
> #3  0x7fffeda626d6 in avcodec_alloc_context3 (codec=0x7fffee3a8900 
> ) at src/libavcodec/options.c:163
> #4  0x7fffef360540 in gst_ffmpeg_cfg_install_property 
> (klass=0x70095200, base=8) at gstavcfg.c:732
> #5  0x7fffef356e53 in gst_ffmpegvidenc_class_init (klass=0x70095200)
> at gstavvidenc.c:225
> #6  0x7788c22d in g_type_class_ref (pclass=0x70094690, 
> node=0x70094500) at 
> /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241
> #7  0x7788c22d in g_type_class_ref (type=type@entry=140737220527360)
> at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956
> #8  0x77b09da4 in gst_element_register (plugin=plugin@entry=0x69bbf0 
> [GstPlugin], name=name@entry=0x7006d110 "avenc_h264_vaapi", 
> rank=rank@entry=128, type=type@entry=140737220527360) at 
> gstelementfactory.c:243
> #9  0x7fffef3575b3 in gst_ffmpegvidenc_register 
> (plugin=plugin@entry=0x69bbf0 [GstPlugin]) at gstavvidenc.c:1009
> #10 0x7fffef349e20 in plugin_init (plugin=0x69bbf0 [GstPlugin])
> at gstav.c:158
> #11 0x77b2b537 in gst_plugin_register_func (plugin=0x69bbf0 
> [GstPlugin], desc=0x7fffef578180 , user_data=0x0) at 
> gstplugin.c:523
> #12 0x77b2d425 in _priv_gst_plugin_load_file_for_registry 
> (filename=0x6c2e20 "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so", 
> registry=0x61c150 [GstRegistry], registry@entry=0x0, 
> error=error@entry=0x74de7bf0)
> at gstplugin.c:826
> #13 0x77b2dcea in gst_plugin_load_file (filename=, 
> error=error@entry=0x74de7bf0) at gstplugin.c:680
> #14 0x77b2e12c in gst_plugin_load_by_name (name=0x6c218d "libav")
> at gstplugin.c:1265
> #15 0x77b2ea8d in gst_plugin_feature_load 
> (feature=feature@entry=0x6e58a0 [GstTypeFindFactory]) at 
> gstpluginfeature.c:111
> #16 0x77b547e3 in gst_type_find_factory_call_function 
> (factory=0x6e58a0 [GstTypeFindFactory], find=0x74de7c90) at 
> gsttypefindfactory.c:210
> #17 0x75d89421 in gst_type_find_helper_for_data 
> (obj=obj@entry=0x812070 [GstWavParse], data=, size= out>, prob=prob@entry=0x74de7db4) at gsttypefindhelper.c:535
> #18 0x75d895a4 in gst_type_find_helper_for_buffer 
> (obj=obj@entry=0x812070 [GstWavParse], buf=buf@entry=0x70003450, 
> prob=prob@entry=0x74de7db4)
> at gsttypefindhelper.c:591
> #19 0x75b3546a in gst_wavparse_add_src_pad (wav=wav@entry=0x812070 
> [GstWavParse], buf=0x70003450) at gstwavparse.c:1908
> #20 0x75b35b47 in gst_wavparse_stream_data (wav=wav@entry=0x812070 
> [GstWavParse]) at gstwavparse.c:2061
> #21 0x75b3bbb1 in gst_wavparse_loop (pad=0x8042a0 [GstPad])
> at gstwavparse.c:2202
> #22 0x77b4fe71 in gst_task_func (task=0x81c050 [GstTask])
> at gsttask.c:332
> #23 0x775bc55e in g_thread_pool_thread_proxy (data=) 
> at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthreadpool.c:307
> #24 0x775bbbc5 in g_thread_proxy (data=0x81a800) at 
> /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthread.c:780
> #25 0x77335464 in start_thread (arg=0x74de8700) at 
> pthread_create.c:333
> #26 0x7707430d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thank you for the info. Could you please let us know the version of libva1 and
i965-va-driver that you have installed? Do you have any other packags providing
va-driver installed?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-22 Thread Carl Eugen Hoyos 
Thank you for the backtrace!

Could you check if removing some or all entries from 
vaapi_encode_h264_defaults in libavcodec/vaapi_encode_h264.c 
fixes the issue? I was unable to quickly find the vaapi 
source file containing the option strings and I don't 
have a cpu with vaapi capabilities.

Thank you, Carl Eugen

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-22 Thread Sebastian Dröge 
On Fri, 22 Jul 2016 13:27:09 +0300 Faidon Liambotis  wrote:

> I still don't exactly understand how H.264/VA-API are related when playing
> just a .wav file, though...

They are not, it's just that the initialization of this GStreamer
plugin (the ffmpeg/libav one) is going through all the codecs that are
provided and remembers what is available.

> #0  0x76fc01c8 in __GI_raise (sig=sig@entry=6)
> at ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76fc164a in __GI_abort () at abort.c:89
> #2  0x7fffeda6260b in init_context_defaults (s=s@entry=0x70095720, 
> codec=codec@entry=0x7fffee3a8900 )
> at src/libavcodec/options.c:142

All the hardware based ffmpeg codecs should be disabled in gst-libav
though. It of course still shouldn't crash like this, which seems like
a problem in ffmpeg, but I'll fix gst-libav to ignore them all now.

signature.asc
Description: This is a digitally signed message part

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-22 Thread Faidon Liambotis 
On Fri, Jul 22, 2016 at 10:21:05AM +0200, Sebastian Ramacher wrote:
> Unfortunately I am unable to reproduce the issue. Since there are some 
> accounts
> of random crashes when building ffmpeg with tree vectorization enabled, I've
> uploaded 7:3.1.1-3 with vectorization disabled. Could you please check if the
> issue disappears with -3?

I upgraded all ffmpeg packages to 7:3.1.1-3 but I'm still experiencing
crashes.

I then installed libavcodec57-dbgsym, libgstreamer1.0-0-dbg,
gstreamer1.0-libav-dbg and gstreamer1.0-plugins-good-dbg. The full
backtrace is below. The "codec = " seems
relevant, since this is on an Intel Broadwell, which may not be the case
for you. This looks a lot like #831529, doesn't it?

I still don't exactly understand how H.264/VA-API are related when playing
just a .wav file, though... This was with the same gstreamer pipeline,
  gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  !
  wavparse ! audioconvert ! fakesink


#0  0x76fc01c8 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x76fc164a in __GI_abort () at abort.c:89
#2  0x7fffeda6260b in init_context_defaults (s=s@entry=0x70095720, 
codec=codec@entry=0x7fffee3a8900 )
at src/libavcodec/options.c:142
#3  0x7fffeda626d6 in avcodec_alloc_context3 (codec=0x7fffee3a8900 
) at src/libavcodec/options.c:163
#4  0x7fffef360540 in gst_ffmpeg_cfg_install_property 
(klass=0x70095200, base=8) at gstavcfg.c:732
#5  0x7fffef356e53 in gst_ffmpegvidenc_class_init (klass=0x70095200)
at gstavvidenc.c:225
#6  0x7788c22d in g_type_class_ref (pclass=0x70094690, 
node=0x70094500) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241
#7  0x7788c22d in g_type_class_ref (type=type@entry=140737220527360)
at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956
#8  0x77b09da4 in gst_element_register (plugin=plugin@entry=0x69bbf0 
[GstPlugin], name=name@entry=0x7006d110 "avenc_h264_vaapi", 
rank=rank@entry=128, type=type@entry=140737220527360) at gstelementfactory.c:243
#9  0x7fffef3575b3 in gst_ffmpegvidenc_register 
(plugin=plugin@entry=0x69bbf0 [GstPlugin]) at gstavvidenc.c:1009
#10 0x7fffef349e20 in plugin_init (plugin=0x69bbf0 [GstPlugin])
at gstav.c:158
#11 0x77b2b537 in gst_plugin_register_func (plugin=0x69bbf0 
[GstPlugin], desc=0x7fffef578180 , user_data=0x0) at 
gstplugin.c:523
#12 0x77b2d425 in _priv_gst_plugin_load_file_for_registry 
(filename=0x6c2e20 "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so", 
registry=0x61c150 [GstRegistry], registry@entry=0x0, 
error=error@entry=0x74de7bf0)
at gstplugin.c:826
#13 0x77b2dcea in gst_plugin_load_file (filename=, 
error=error@entry=0x74de7bf0) at gstplugin.c:680
#14 0x77b2e12c in gst_plugin_load_by_name (name=0x6c218d "libav")
at gstplugin.c:1265
#15 0x77b2ea8d in gst_plugin_feature_load 
(feature=feature@entry=0x6e58a0 [GstTypeFindFactory]) at gstpluginfeature.c:111
#16 0x77b547e3 in gst_type_find_factory_call_function (factory=0x6e58a0 
[GstTypeFindFactory], find=0x74de7c90) at gsttypefindfactory.c:210
#17 0x75d89421 in gst_type_find_helper_for_data (obj=obj@entry=0x812070 
[GstWavParse], data=, size=, 
prob=prob@entry=0x74de7db4) at gsttypefindhelper.c:535
#18 0x75d895a4 in gst_type_find_helper_for_buffer 
(obj=obj@entry=0x812070 [GstWavParse], buf=buf@entry=0x70003450, 
prob=prob@entry=0x74de7db4)
at gsttypefindhelper.c:591
#19 0x75b3546a in gst_wavparse_add_src_pad (wav=wav@entry=0x812070 
[GstWavParse], buf=0x70003450) at gstwavparse.c:1908
#20 0x75b35b47 in gst_wavparse_stream_data (wav=wav@entry=0x812070 
[GstWavParse]) at gstwavparse.c:2061
#21 0x75b3bbb1 in gst_wavparse_loop (pad=0x8042a0 [GstPad])
at gstwavparse.c:2202
#22 0x77b4fe71 in gst_task_func (task=0x81c050 [GstTask])
at gsttask.c:332
#23 0x775bc55e in g_thread_pool_thread_proxy (data=) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthreadpool.c:307
#24 0x775bbbc5 in g_thread_proxy (data=0x81a800) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthread.c:780
#25 0x77335464 in start_thread (arg=0x74de8700) at 
pthread_create.c:333
#26 0x7707430d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109


Thanks,
Faidon

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-22 Thread Sebastian Ramacher 
Hi

On 2016-07-20 22:06:05, Faidon Liambotis wrote:
> Package: libavcodec57
> Version: 7:3.1.1-2
> Severity: grave
> 
> I ran Debian testing on my desktop. Since about a day ago, pidgin
> started crashing unexpectedly. After a little bit of debugging, I found
> that it reproducibly crashes when trying to play sounds. Going a step
> further, I made the test case as simple as:
> 
> $ gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  ! 
> wavparse ! audioconvert !  fakesink
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Aborted (core dumped)

Unfortunately I am unable to reproduce the issue. Since there are some accounts
of random crashes when building ffmpeg with tree vectorization enabled, I've
uploaded 7:3.1.1-3 with vectorization disabled. Could you please check if the
issue disappears with -3?

> My dpkg.log has a bunch of ffmpeg-related package upgrades, including
> libavcodec57, being installed on 2016-07-18, approximately when those
> crashes started. Because of this and the backtrace below, I'm filing
> this against libavcodec57 -- feel free to reassign if that's wrong.
> 
> The backtrace seems to be:
>PID: 4121 (gst-launch-1.0)
>UID: 1000 (paravoid)
>GID: 1000 (paravoid)
> Signal: 6 (ABRT)
>  Timestamp: Τετ 2016-07-20 21:55:59 EEST (5min ago)
>   Command Line: gst-launch-1.0 filesrc 
> location=/usr/share/sounds/purple/alert.wav ! wavparse ! audioconvert ! 
> fakesink
> Executable: /usr/bin/gst-launch-1.0
>  Control Group: /
>  Slice: -.slice
>Boot ID: fc3d59275e1042c491633f9a920c10e5
> Machine ID: ddb673bb6861472487a0edbc40f6f1fc
>   Hostname: donald
>   Coredump: 
> /var/lib/systemd/coredump/core.gst-launch-1\x2e0.1000.fc3d59275e1042c491633f9a920c10e5.4121.1469040959.xz
>Message: Process 4121 (gst-launch-1.0) of user 1000 dumped core.
> 
> Stack trace of thread 4122:
> #0  0x7fa47ae7f1c8 raise (libc.so.6)
> #1  0x7fa47ae8064a abort (libc.so.6)
> #2  0x7fa4719b8f5b n/a (libavcodec.so.57)
> #3  0x7fa4719b9026 avcodec_alloc_context3 
> (libavcodec.so.57)
> #4  0x7fa473360540 n/a (libgstlibav.so)
> #5  0x7fa473356e53 n/a (libgstlibav.so)
> #6  0x7fa47b74b22d g_type_class_ref (libgobject-2.0.so.0)
> #7  0x7fa47b9c8da4 gst_element_register 
> (libgstreamer-1.0.so.0)
> #8  0x7fa4733575b3 n/a (libgstlibav.so)
> #9  0x7fa473349e20 n/a (libgstlibav.so)
> #10 0x7fa47b9ea537 n/a (libgstreamer-1.0.so.0)
> #11 0x7fa47b9ec425 n/a (libgstreamer-1.0.so.0)
> #12 0x7fa47b9ed12c gst_plugin_load_by_name 
> (libgstreamer-1.0.so.0)
> #13 0x7fa47b9eda8d gst_plugin_feature_load 
> (libgstreamer-1.0.so.0)
> #14 0x7fa47ba137e3 gst_type_find_factory_call_function 
> (libgstreamer-1.0.so.0)
> #15 0x7fa479c48421 gst_type_find_helper_for_data 
> (libgstbase-1.0.so.0)
> #16 0x7fa479c485a4 gst_type_find_helper_for_buffer 
> (libgstbase-1.0.so.0)
> #17 0x7fa4799f446a n/a (libgstwavparse.so)
> #18 0x7fa4799f4b47 n/a (libgstwavparse.so)
> #19 0x7fa4799fabb1 n/a (libgstwavparse.so)
> #20 0x7fa47ba0ee71 n/a (libgstreamer-1.0.so.0)
> #21 0x7fa47b47b55e n/a (libglib-2.0.so.0)
> #22 0x7fa47b47abc5 n/a (libglib-2.0.so.0)
> #23 0x7fa47b1f4464 start_thread (libpthread.so.0)
> #24 0x7fa47af3330d __clone (libc.so.6)
> 
> Stack trace of thread 4121:
> #0  0x7fa47af2a19d poll (libc.so.6)
> #1  0x7fa47b45439c n/a (libglib-2.0.so.0)
> #2  0x7fa47b454722 g_main_loop_run (libglib-2.0.so.0)
> #3  0x7fa47b9af8e9 gst_bus_poll (libgstreamer-1.0.so.0)
> #4  0x004046f8 n/a (gst-launch-1.0)
> #5  0x004036e9 n/a (gst-launch-1.0)
> #6  0x7fa47ae6c730 __libc_start_main (libc.so.6)
> #7  0x00403d19 n/a (gst-launch-1.0)
> 
> Stack trace of thread 4123:
> #0  0x7fa47af2a19d poll (libc.so.6)
> #1  0x7fa47b45439c n/a (libglib-2.0.so.0)
> #2  0x7fa47b4544ac g_main_context_iteration 
> (libglib-2.0.so.0)
> #3  0x7fa47b4544e9 n/a (libglib-2.0.so.0)
> #4  0x7fa47b47abc5 n/a (libglib-2.0.so.0)
> #5  0x7fa47b1f4464 start_thread (libpthread.so.0)
> #6  0x7fa47af3330d __clone (libc.so.6)

Please install libavcodec57-dbgsym and the -dbgsym packages

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-21 Thread Carl Eugen Hoyos 
If the issue is reproducible, please someone test if it disappears once you 
recompile GStreamer against the installed libavcodec headers.

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-21 Thread Sebastian Dröge 
On Wed, 20 Jul 2016 22:06:05 +0300 Faidon Liambotis  wrote:

> Stack trace of thread 4122:
> #0  0x7fa47ae7f1c8 raise (libc.so.6)
> #1  0x7fa47ae8064a abort (libc.so.6)
> #2  0x7fa4719b8f5b n/a (libavcodec.so.57)
> #3  0x7fa4719b9026 avcodec_alloc_context3 
>(libavcodec.so.57)
> #4  0x7fa473360540 n/a (libgstlibav.so)
> #5  0x7fa473356e53 n/a (libgstlibav.so)
> #6  0x7fa47b74b22d g_type_class_ref (libgobject-2.0.so.0)
> #7  0x7fa47b9c8da4 gst_element_register 
>(libgstreamer-1.0.so.0)
> #8  0x7fa4733575b3 n/a (libgstlibav.so)
> #9  0x7fa473349e20 n/a (libgstlibav.so)
> #10 0x7fa47b9ea537 n/a (libgstreamer-1.0.so.0)
> #11 0x7fa47b9ec425 n/a (libgstreamer-1.0.so.0)
> #12 0x7fa47b9ed12c gst_plugin_load_by_name 
>(libgstreamer-1.0.so.0)
> #13 0x7fa47b9eda8d gst_plugin_feature_load 
>(libgstreamer-1.0.so.0)
> #14 0x7fa47ba137e3 gst_type_find_factory_call_function 
>(libgstreamer-1.0.so.0)
> #15 0x7fa479c48421 gst_type_find_helper_for_data 
>(libgstbase-1.0.so.0)
> #16 0x7fa479c485a4 gst_type_find_helper_for_buffer 
>(libgstbase-1.0.so.0)
> #17 0x7fa4799f446a n/a (libgstwavparse.so)
> #18 0x7fa4799f4b47 n/a (libgstwavparse.so)
> #19 0x7fa4799fabb1 n/a (libgstwavparse.so)
> #20 0x7fa47ba0ee71 n/a (libgstreamer-1.0.so.0)
> #21 0x7fa47b47b55e n/a (libglib-2.0.so.0)
> #22 0x7fa47b47abc5 n/a (libglib-2.0.so.0)
> #23 0x7fa47b1f4464 start_thread (libpthread.so.0)

Thanks for the report. Can you install debug symbols for libavcodec57
and get another backtrace?

Also what's the assertion you see on the terminal that causes the
abort()?

Do you have the same problem with gstreamer1.0-libav from experimental
(version 1.9.1-1)? I can't reproduce this here with either 1.8.2-1 or
1.9.1-1 unfortunately.

signature.asc
Description: This is a digitally signed message part

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

2016-07-20 Thread Faidon Liambotis 
Package: libavcodec57
Version: 7:3.1.1-2
Severity: grave

I ran Debian testing on my desktop. Since about a day ago, pidgin
started crashing unexpectedly. After a little bit of debugging, I found
that it reproducibly crashes when trying to play sounds. Going a step
further, I made the test case as simple as:

$ gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  ! 
wavparse ! audioconvert !  fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Aborted (core dumped)

My dpkg.log has a bunch of ffmpeg-related package upgrades, including
libavcodec57, being installed on 2016-07-18, approximately when those
crashes started. Because of this and the backtrace below, I'm filing
this against libavcodec57 -- feel free to reassign if that's wrong.

The backtrace seems to be:
   PID: 4121 (gst-launch-1.0)
   UID: 1000 (paravoid)
   GID: 1000 (paravoid)
Signal: 6 (ABRT)
 Timestamp: Τετ 2016-07-20 21:55:59 EEST (5min ago)
  Command Line: gst-launch-1.0 filesrc 
location=/usr/share/sounds/purple/alert.wav ! wavparse ! audioconvert ! fakesink
Executable: /usr/bin/gst-launch-1.0
 Control Group: /
 Slice: -.slice
   Boot ID: fc3d59275e1042c491633f9a920c10e5
Machine ID: ddb673bb6861472487a0edbc40f6f1fc
  Hostname: donald
  Coredump: 
/var/lib/systemd/coredump/core.gst-launch-1\x2e0.1000.fc3d59275e1042c491633f9a920c10e5.4121.1469040959.xz
   Message: Process 4121 (gst-launch-1.0) of user 1000 dumped core.

Stack trace of thread 4122:
#0  0x7fa47ae7f1c8 raise (libc.so.6)
#1  0x7fa47ae8064a abort (libc.so.6)
#2  0x7fa4719b8f5b n/a (libavcodec.so.57)
#3  0x7fa4719b9026 avcodec_alloc_context3 (libavcodec.so.57)
#4  0x7fa473360540 n/a (libgstlibav.so)
#5  0x7fa473356e53 n/a (libgstlibav.so)
#6  0x7fa47b74b22d g_type_class_ref (libgobject-2.0.so.0)
#7  0x7fa47b9c8da4 gst_element_register 
(libgstreamer-1.0.so.0)
#8  0x7fa4733575b3 n/a (libgstlibav.so)
#9  0x7fa473349e20 n/a (libgstlibav.so)
#10 0x7fa47b9ea537 n/a (libgstreamer-1.0.so.0)
#11 0x7fa47b9ec425 n/a (libgstreamer-1.0.so.0)
#12 0x7fa47b9ed12c gst_plugin_load_by_name 
(libgstreamer-1.0.so.0)
#13 0x7fa47b9eda8d gst_plugin_feature_load 
(libgstreamer-1.0.so.0)
#14 0x7fa47ba137e3 gst_type_find_factory_call_function 
(libgstreamer-1.0.so.0)
#15 0x7fa479c48421 gst_type_find_helper_for_data 
(libgstbase-1.0.so.0)
#16 0x7fa479c485a4 gst_type_find_helper_for_buffer 
(libgstbase-1.0.so.0)
#17 0x7fa4799f446a n/a (libgstwavparse.so)
#18 0x7fa4799f4b47 n/a (libgstwavparse.so)
#19 0x7fa4799fabb1 n/a (libgstwavparse.so)
#20 0x7fa47ba0ee71 n/a (libgstreamer-1.0.so.0)
#21 0x7fa47b47b55e n/a (libglib-2.0.so.0)
#22 0x7fa47b47abc5 n/a (libglib-2.0.so.0)
#23 0x7fa47b1f4464 start_thread (libpthread.so.0)
#24 0x7fa47af3330d __clone (libc.so.6)

Stack trace of thread 4121:
#0  0x7fa47af2a19d poll (libc.so.6)
#1  0x7fa47b45439c n/a (libglib-2.0.so.0)
#2  0x7fa47b454722 g_main_loop_run (libglib-2.0.so.0)
#3  0x7fa47b9af8e9 gst_bus_poll (libgstreamer-1.0.so.0)
#4  0x004046f8 n/a (gst-launch-1.0)
#5  0x004036e9 n/a (gst-launch-1.0)
#6  0x7fa47ae6c730 __libc_start_main (libc.so.6)
#7  0x00403d19 n/a (gst-launch-1.0)

Stack trace of thread 4123:
#0  0x7fa47af2a19d poll (libc.so.6)
#1  0x7fa47b45439c n/a (libglib-2.0.so.0)
#2  0x7fa47b4544ac g_main_context_iteration 
(libglib-2.0.so.0)
#3  0x7fa47b4544e9 n/a (libglib-2.0.so.0)
#4  0x7fa47b47abc5 n/a (libglib-2.0.so.0)
#5  0x7fa47b1f4464 start_thread (libpthread.so.0)
#6  0x7fa47af3330d __clone (libc.so.6)

Finally, note that running "mpv /usr/share/sounds/purple/receive.wav"
seems to work without crashing (and produces sound), however, there is a
big yellow warning at the top that reads: "Warning: mpv was compiled
against a different version of ffmpeg than the shared library it is
linked against. This is most likely a broken build and misbehavior and
crashes are to be expected."

Thanks,
Faidon

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')