Hi. I reported bug #833333 against the Amarok package, but it is probably due to gstreamer. So gstreamer maintainers are in Cc.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833333 I found how to intercept amarok's backtrace (use "amarok --nofork"). So that is the backtrace: > 0x00007ffff4a751c8 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:54 > 54 ../sysdeps/unix/sysv/linux/raise.c: File o directory non esistente. > (gdb) bt > #0 0x00007ffff4a751c8 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:54 > #1 0x00007ffff4a7664a in __GI_abort () at abort.c:89 > #2 0x00007ffff1d7560b in init_context_defaults (s=s@entry=0x7ffe6c077ce0, > codec=codec@entry=0x7ffff26bb900 <ff_h264_vaapi_encoder>) at > src/libavcodec/options.c:142 > #3 0x00007ffff1d756d6 in avcodec_alloc_context3 (codec=0x7ffff26bb900 > <ff_h264_vaapi_encoder>) at src/libavcodec/options.c:163 > #4 0x00007fff04558540 in gst_ffmpeg_cfg_install_property > (klass=0x7ffe6c077550, base=8) at gstavcfg.c:732 > #5 0x00007fff0454ee53 in gst_ffmpegvidenc_class_init (klass=0x7ffe6c077550) > at gstavvidenc.c:225 > #6 0x00007fffecf2722d in g_type_class_ref (pclass=0x7ffe6c077220, > node=0x7ffe6c076f40) at > /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241 > #7 0x00007fffecf2722d in g_type_class_ref (type=type@entry=140730710847296) > at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956 > #8 0x00007fffdf246da4 in gst_element_register (plugin=plugin@entry=0xbe1160 > [GstPlugin], name=name@entry=0x7ffe6c06eeb0 "avenc_h264_vaapi", > rank=rank@entry=128, type=type@entry=140730710847296) at > gstelementfactory.c:243 > #9 0x00007fff0454f5b3 in gst_ffmpegvidenc_register > (plugin=plugin@entry=0xbe1160 [GstPlugin]) at gstavvidenc.c:1009 > #10 0x00007fff04541e20 in plugin_init (plugin=0xbe1160 [GstPlugin]) at > gstav.c:158 > #11 0x00007fffdf268537 in gst_plugin_register_func (plugin=0xbe1160 > [GstPlugin], desc=0x7fff04770180 <gst_plugin_desc>, user_data=0x0) at > gstplugin.c:523 > #12 0x00007fffdf26a425 in _priv_gst_plugin_load_file_for_registry > (filename=0xbe4d00 "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so", > registry=0x92b2b0 [GstRegistry], registry@entry=0x0, > error=error@entry=0x7fff04f71800) > at gstplugin.c:826 > #13 0x00007fffdf26acea in gst_plugin_load_file (filename=<optimized out>, > error=error@entry=0x7fff04f71800) at gstplugin.c:680 > #14 0x00007fffdf26b12c in gst_plugin_load_by_name (name=0xbe378a "libav") at > gstplugin.c:1265 > #15 0x00007fffdf26ba8d in gst_plugin_feature_load > (feature=feature@entry=0xc0b360 [GstTypeFindFactory]) at > gstpluginfeature.c:111 > #16 0x00007fffdf2917e3 in gst_type_find_factory_call_function > (factory=0xc0b360 [GstTypeFindFactory], find=0x7fff04f718e0) at > gsttypefindfactory.c:210 > #17 0x00007fffdf55e0c9 in gst_type_find_helper_get_range > (obj=obj@entry=0xd7eec0 [GstID3Demux], parent=parent@entry=0x0, > func=func@entry=0x7fffdad05600 <gst_tag_demux_read_range>, size=<optimized > out>, extension=extension@entry=0x0, prob=prob@entry=0x7fff04f719ac) at > gsttypefindhelper.c:355 > #18 0x00007fffdad02cc8 in gst_tag_demux_element_find (demux=0xd7eec0 > [GstID3Demux]) at gsttagdemux.c:1364 > #19 0x00007fffdad03d8d in gst_tag_demux_element_loop (demux=0xd7eec0 > [GstID3Demux]) at gsttagdemux.c:1437 > #20 0x00007fffdf28ce71 in gst_task_func (task=0x92d950 [GstTask]) at > gsttask.c:332 > #21 0x00007fffed8b855e in g_thread_pool_thread_proxy (data=<optimized out>) > at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthreadpool.c:307 > #22 0x00007fffed8b7bc5 in g_thread_proxy (data=0x7ffe740fcde0) at > /build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthread.c:780 > #23 0x00007ffff36d0464 in start_thread (arg=0x7fff04f72700) at > pthread_create.c:333 > #24 0x00007ffff4b2930d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Which seems to indicate that the bug is in gstreamer1.0-libav. And actually upgrading that package to the experimental version (1.9.1-1) fixes the bug. So I leave it to the GStreamer maintainers to decide what to do with the bug (if 1.9.1-1 is planned to migrate to unstable and testing soon, there is no need to fix 1.8.2-1; if not, probably it is a good idea to do that). Thanks, Giovanni. -- Giovanni Mascellani <g.mascell...@gmail.com> PhD Student - Scuola Normale Superiore, Pisa, Italy http://poisson.phc.unipi.it/~mascellani
signature.asc
Description: OpenPGP digital signature
