GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Invalid argument. Aborting.

[Sergei Vorobyov]

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_m
>> utex_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/8381b86a/attachment-0001.html>