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

[Sergei Vorobyov]

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/039eb5cd/attachment.html>