GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Invalid argument. Aborting.
Sergei Vorobyov
sergei.vorobyov at facilitylabs.com
Tue Sep 23 03:57:06 PDT 2014
No matter whether I leave the non-video stream pad alone ("ignoring..." in
my callback above), or I link it to the static "sink" pad of fakesink, the
Unexpected error from C library during 'p_thread_mutex_lock'. Invalid
argument. Aborting (with core dumped)
happens frequently with vaapisink and i965_drv_video.so, but does not
happen at all on NVidia Quadro FX580, without video acceleration.
On Tue, Sep 23, 2014 at 11:56 AM, Sergei Vorobyov <
sergei.vorobyov at facilitylabs.com> wrote:
> Sorry for my previous garbled code. Here's a better callback attempt which
> discriminates between two cases: 1) when decodebin adds a video pad and 2)
> when decodebin adds a non-video (audio pad).
>
> I have two questions:
> 1) can the non-video pad (see the "ignoring" case below) be left without
> linking, or it must be linked to the fakesink?
> 2) should str be unreffed?
> 3) should str_name be g_freed? (or it belongs to the internals?)
>
> Thanks, I could not find the answers in the manuals/APIs
>
> static void composition_new_pad (GstElement *decodebin, GstPad *pad,
> gpointer identity) {
> LOG_INFO("dynamically linking %s to %s...", GST_OBJECT_NAME
> (decodebin), GST_OBJECT_NAME (identity));
> GstCaps *caps = gst_pad_query_caps (pad, NULL);
> GstStructure *str = gst_caps_get_structure (caps, 0);
> gchar const *str_name = gst_structure_get_name (str);
> if (!g_str_has_prefix (str_name, "video")) {
> LOG_INFO("non-video pad type: %s, ignoring...", str_name);
> gst_caps_unref (caps);
> return;
> }
> if (gst_pad_is_linked (pad)) {
> LOG_INFO("already linked!");
> gst_caps_unref (caps);
> return;
> }
> GstPad *sinkpad = gst_element_get_compatible_pad ((GstElement*)
> identity, pad, caps);
> gst_caps_unref (caps);
> if (!sinkpad) {
> LOG_INFO("empty sinkpad, ignore and return");
> //LOG_ERROR("can't create sinkpad on %s", GST_OBJECT_NAME (data));
> return;
> }
> GstPadLinkReturn pad_link_outcome = gst_pad_link (pad, sinkpad);
> if (pad_link_outcome == GST_PAD_LINK_OK)
> LOG_INFO("success!");
> else
> LOG_ERROR("composition_new_pad(): gst_pad_link() failed with code %d",
> pad_link_outcome);
> gst_object_unref (sinkpad);
> }
>
>
> On Tue, Sep 23, 2014 at 11:31 AM, Sergei Vorobyov <
> sergei.vorobyov at facilitylabs.com> wrote:
>
>> please disregard my erroneous callback code in the previous message,
>> which I accidentally sent before finishing
>>
>> On Tue, Sep 23, 2014 at 11:29 AM, Sergei Vorobyov <
>> sergei.vorobyov at facilitylabs.com> wrote:
>>
>>> A partial answer to myself:
>>>
>>> the .wmv media files in question cause decodebin call the callback
>>> function twice in quick succession, once for video, once for audio
>>>
>>> I can discriminate between these cases using the following callback:
>>>
>>> static void composition_new_pad (GstElement *element, GstPad *pad,
>>> gpointer data) {
>>> LOG_INFO("dynamically linking %s to %s...", GST_OBJECT_NAME
>>> (element), GST_OBJECT_NAME (data));
>>> GstCaps *caps = gst_pad_query_caps (pad, NULL);
>>> GstStructure *str = gst_caps_get_structure (caps, 0);
>>> gchar const *str_name = gst_structure_get_name (str);
>>> if (!g_str_has_prefix (str_name, "video")) {
>>> LOG_INFO("non-video pad type: %s, ignoring...", str_name);
>>>
>>> return;
>>> }
>>> gst_caps_unref (caps);
>>> if (gst_pad_is_linked (pad)) {
>>> LOG_INFO("already linked!");
>>> return;
>>> }
>>> GstPad *sinkpad =
>>> gst_element_get_compatible_pad ((GstElement*) data, // identity
>>> pad,
>>> gst_pad_query_caps (pad, NULL)); // struct GstPad
>>> if (!sinkpad) {
>>> LOG_INFO("empty sinkpad, ignore and return");
>>> //LOG_ERROR("can't create sinkpad on %s", GST_OBJECT_NAME (data));
>>> return;
>>> }
>>> GstPadLinkReturn pad_link_outcome = gst_pad_link (pad, sinkpad);
>>> if (pad_link_outcome == GST_PAD_LINK_OK)
>>> LOG_INFO("success!");
>>> else {
>>> LOG_ERROR("composition_new_pad(): gst_pad_link() failed with code %d",
>>> pad_link_outcome);
>>> }
>>> gst_object_unref (sinkpad);
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Sep 22, 2014 at 2:01 PM, Sergei Vorobyov <
>>> sergei.vorobyov at facilitylabs.com> wrote:
>>>
>>>> This error
>>>>
>>>> GLib (gthread-posix.c): Unexpected error from C library during
>>>> 'pthread_mutex_lock': Invalid argument. Aborting.
>>>>
>>>> frequently happens when I am using vaapisink with i964_drv_video.so on
>>>> Intel built-in graphics of NUC DN2820FYKH
>>>>
>>>> but *never* happens if I use ximagesink without video acceleration on
>>>> NVidia Quadro FX580, without video acceleration (btw, I am missing
>>>> /usb/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so and cannot find it in
>>>> any packages).
>>>>
>>>> From this I plausibly conclude that my code is innocent.
>>>>
>>>> Googling for the above error produces many reports, but nothing that
>>>> makes sense to me.
>>>>
>>>> After adding some debugging code I also suspect that the .wmv files may
>>>> be the issue:
>>>>
>>>> 1. I am playing different media files through the same pipeline by
>>>> varying different location=.... for the filesrc element
>>>>
>>>> 2. I am dynamically linking decodebin with identity, using
>>>> g_signal_connect.
>>>>
>>>> 3. For that purpose I g_signal_connect decodebin on "pad-added" with a
>>>> callback that is usually called ONCE per .avi files,
>>>>
>>>> 4. but TWICE in a very quick succession (a few milliseconds) on .wmv
>>>> files. The first call returns a non-NULL sinkpad = gst_get_compatible_pad
>>>> (identity, ...), which I link with the source pad of decodebin. The second
>>>> call is problematic, it returns NULL==gst_get_compatible_pad (identity,
>>>> ....). I can do nothing but ignore/return for that second call. The pipe
>>>> plays invariably OK on NVidia without video acceleration but frequently
>>>> breaks on i964_drv_video.so with video acceleration and vaapisink
>>>>
>>>> 5. Remark: I do not play sound, just images and video. I just relink
>>>> the pipe (in C) between
>>>>
>>>> filesrc ! decodebin ! identity ! imagefreeze ! videoconvert !
>>>> <videosink> for still images and
>>>> filesrc ! decodebin ! identity ! videoconvert ! <videosink> for movies
>>>>
>>>> Maybe this explains everything to you?
>>>>
>>>>
>>>>
>>>> On Sun, Sep 21, 2014 at 3:40 PM, Tim Müller <tim at centricular.com>
>>>> wrote:
>>>>
>>>>> On Fri, 2014-09-19 at 14:08 +0200, Sergei Vorobyov wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> > GStreamer 1.2.4 and GLib v2.40.0
>>>>> > I recently started to systematically get the following error:
>>>>>
>>>>> > GLib (gthread-posix.c): Unexpected error from C library during
>>>>> > 'pthread_mutex_lock': Invalid argument. Aborting.
>>>>> >
>>>>> >
>>>>> > [I preliminary guess it started when I switched from ximagesink to
>>>>> > vaapisink,
>>>>> > but this remains to be investigated]
>>>>> >
>>>>> >
>>>>> > That does not come from my code and looks like a programming error.
>>>>> > Sure I use a few threads, but those are initialized in the very
>>>>> > beginning and run as infinite loops, nothing fancy.
>>>>>
>>>>> How do you know it's not from your code? It may be unlikely, but it
>>>>> could also be some memory corruption caused by your code.
>>>>>
>>>>> > Apparently, it's a long-standing issue. There are many reports, but
>>>>> > they don't explain nor fix the issue.
>>>>>
>>>>> It's the first time I hear about it. Many reports where? Is there a
>>>>> report in bugzilla? If not, please file one, ideally with a stack trace
>>>>> and if available also valgrind output (after installing libc, glib and
>>>>> gst debugging symbols).
>>>>>
>>>>> Cheers
>>>>> -Tim
>>>>>
>>>>> --
>>>>> Tim Müller, Centricular Ltd - http://www.centricular.com
>>>>>
>>>>> _______________________________________________
>>>>> gstreamer-devel mailing list
>>>>> gstreamer-devel at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140923/29c2f8a0/attachment-0001.html>
More information about the gstreamer-devel
mailing list