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

[Sergei Vorobyov]

> I clipped a very small program, no threads, from my code which unrefs
nothing (except one NONEMPTY message gst_bus_pop_filtered from the bus to
detect
> EOS, ERROR, SEGMENT_DONE, time expired) but fails the same way very
quickly playing just two .wmv files in a cycle
> on i965_drv_video.so through filesrc location=... ! decodebin !
videoconvert ! autovideosink.

It fails the same way with vaapisink with

Unexpected error from C library during 'p_thread_mutex_lock'. Invalid
argument. Aborting


But the same simple program is rock-solid if I play the same two media
files converted to .mp4 in an infinite cycle, on the same platform.

Conclusion: there's something wrong specific to .wmv files in decodebin,
videoconvert, autovideosink, vaapisink, and i965_drv_video.so, it's not my
error.

I don't have enough knowledge to debug decodebin, videoconvert,
autovideosink, vaapisink, and i965_drv_video.so. I think it's already
useless: I am with the Ubuntu 14.04 stock GStreamer 1.2.4, and the mailing
list is already talking version 1.4


On Tue, Sep 23, 2014 at 5:28 PM, Sergei Vorobyov <
sergei.vorobyov at facilitylabs.com> wrote:

> I clipped a very small program, no threads, from my code which unrefs
> nothing (except one NONEMPTY message gst_bus_pop_filtered from the bus to
> detect EOS, ERROR, SEGMENT_DONE, time expired) but fails the same way very
> quickly playing just two .wmv files in a cycle on i965_drv_video.so
> through filesrc location=... ! decodebin ! videoconvert ! autovideosink.
>
> I will carefully inspect it and then proceed to valgrinding it.
>
> Thanks for the hints!
>
> On Tue, Sep 23, 2014 at 4:12 PM, Nicolas Dufresne <
> nicolas.dufresne at collabora.com> wrote:
>
>>
>> Le 2014-09-23 09:57, Sergei Vorobyov a écrit :
>>
>>> The art of debugging is about zooming in on the real problem, cutting
>>> off trivial or nonessential things, not to debug everything altogether with
>>> the biggest hammer available.
>>>
>> Up to you, my far guess is that you actually unref too much something
>> somewhere, and endup doing "use after free" object that holds a mutex and
>> crash. Normally, valgrind, with the environment G_SLICE=always_malloc gives
>> an overview of that very quickly, and can often be done before cutting down
>> you pipeline. I say you, because it's an habit to blame the new and shiny
>> code, but obviously it's not impossible that libvaapi or the graphic driver
>> is bugged. You have already said that without HW acceleration it's fine.
>>
>>
>> Nicolas
>> _______________________________________________
>> 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/20140924/8fbbb267/attachment.html>