I'm using GStreamer 1.4.5 version.

George, the display ownership stuff got fixed since, right?

This doesn't look like a waylandsink bug. The crash happens at the point where waylandsink requests the display handle (wl_display) from the application. Then, because it's the second time the file is being played, playbin gives the display handle context that it had cached from the first time (playbin caches all GstContext) to waylandsink and waylandsink crashes in wl_display_get_registry(), so I would assume that the wl_display pointer is invalid. This can only happen if the application disconnects from the display and re-connects while playbin is in the NULL state, I suppose... Do you do anything like that in your application?

Hi George,
I'm a greenhorn in using gstramer. All we tried to do was to reuse a pipeline for a different media(video) file(same thing tried and worked in case of mp3 files). Right now we workaround this by using a new pipeline(but I'm not sure that is best practice). Same thing was tested(reusing the pipeline) on desktop AMD64 machine(ubuntu 14) and worked.

Would it be possible to provide a simplified C program that reproduce this issue. This way we can test if we can reproduce this crash and also check if it was fixed in newer version (allowing to identify potential patches that may help). We also need to make sure this is a bug on GStreamer side rather then on libwayland side.

Created attachment 313838 [details]
Demo app that replicates crash

Created attachment 313839 [details]
Demo app bt

Hello guys,
I'm Catalin's colleague. I attached the code of a small test app that is supposed to play two movies and replicates the crash. I also added the bt and it is pretty similar to the one we got in our player. Hope this helps.

Thanks Cristian.

Thanks, I can reproduce it in gst master with your demo. I'm on it...

commit c2f34b981427f2698ce47195627a40894b640962
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Mon Oct 26 15:30:08 2015 +0100

    waylandsink: don't advertise the local wl_display context

    This wl_display proxy is temporary only until waylandsink goes NULL,
    at which point the connection to the display is disposed. Unfortunately,
    if this is advertised as a GstContext, playbin will cache it and re-feed
    it to the sink when it goes PLAYING again, but the wl_display pointer
    will at that point be invalid and cause a crash.

    Another solution to the problem would be to also cache the GstWlDisplay
    object inside the GstContext, which would automatically ref-count
    the display connection, but I see no reason in doing that at the moment,
    as there are no known users of this GstContext outside waylandsink.
    It's probably better to avoid chasing hidden refcounts.

    https://bugzilla.gnome.org/show_bug.cgi?id=756567

Backported also to 1.6.x:

commit 450bac6ce59a72ce45cda6bc128fef56dada419a
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Mon Oct 26 15:30:08 2015 +0100

    waylandsink: don't advertise the local wl_display context

    This wl_display proxy is temporary only until waylandsink goes NULL,
    at which point the connection to the display is disposed. Unfortunately,
    if this is advertised as a GstContext, playbin will cache it and re-feed
    it to the sink when it goes PLAYING again, but the wl_display pointer
    will at that point be invalid and cause a crash.

    Another solution to the problem would be to also cache the GstWlDisplay
    object inside the GstContext, which would automatically ref-count
    the display connection, but I see no reason in doing that at the moment,
    as there are no known users of this GstContext outside waylandsink.
    It's probably better to avoid chasing hidden refcounts.

    https://bugzilla.gnome.org/show_bug.cgi?id=756567

We tested the patch and worked well

Thank you !!!