After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 393975 - closing x/xvimagesink window crashes gst-launch
closing x/xvimagesink window crashes gst-launch
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal normal
: 0.10.13
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2007-01-07 18:20 UTC by Ronald Bultje
Modified: 2007-05-18 08:23 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Ronald Bultje 2007-01-07 18:20:04 UTC
$ gst-launch-0.10 videotestsrc ! ximagesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

<- now click the X in the popped up window ->

X connection to :0.0 broken (explicit kill or server shutdown).

The same happens with xvimagesink. This leads to problems in applications, such as gstreamer-properties, who are using the pop-up window. It would be better if the pipeline would go into READY or in some other way behaves decently.
Comment 1 Julien MOUTTE 2007-01-22 13:21:51 UTC
Can't reproduce.. When i close the window gst-launch just exit without this X error message you are describing.
Comment 2 Ronald Bultje 2007-01-22 13:47:38 UTC
so what happens when you close the window in gstreamer-properties? And does the pipeline go into gst-state-ready like I suggested, i.e. is the app notified of the window closure so it can present said information to the user?
Comment 3 Tim-Philipp Müller 2007-01-30 11:20:06 UTC
I get such a message (or some other Xlib-message) about one out of two times when I close the xwindow. At other times I don't get a message at all.

In all cases exit() is called somewhere inside XLib (?) it seems, and the program just terminates (and the application can't do anything about it).

Comment 4 David Schleef 2007-01-30 23:01:50 UTC
Any volunteers for migrating to xcb?  :)
Comment 5 Ronald Bultje 2007-04-09 12:48:59 UTC
This bug (or, if you don't call this a bug, then call it unwanted behaviour) still exists in gst-properties, can this please be reopened?
Comment 6 Tim-Philipp Müller 2007-05-03 12:09:42 UTC
> This bug (or, if you don't call this a bug, then call it unwanted behaviour)
> still exists in gst-properties, can this please be reopened?

Is this even fixable on our end?

Comment 7 Ronald Bultje 2007-05-03 12:16:44 UTC
You're asking me?

I can come up with some ways to fix it, none of them completely pretty, but sure, there's some ways. Gtk has a way of having apps pop up a confirmation dialog when pressing 'X' in the window manager (not-gtk) bar, so you should be able to do that also. See what gtk does there.

From there on, it's all on whatever API you decide this "feature" should have. I'd recommend that 'X' would send a request-for-eos or so to the app, but there's a variety of ways to make this work...
Comment 8 David Schleef 2007-05-03 22:29:20 UTC
xcb will fix it :)
Comment 9 Jan Schmidt 2007-05-17 17:37:38 UTC
Fixed in CVS:

2007-05-17  Jan Schmidt  <>

        * sys/ximage/ximagesink.c: (gst_ximagesink_ximage_put),
        (gst_ximagesink_xwindow_new), (gst_ximagesink_handle_xevents),
        * sys/xvimage/xvimagesink.c: (gst_xvimagesink_xvimage_put),
        (gst_xvimagesink_xwindow_new), (gst_xvimagesink_handle_xevents),
        When we create our own window, indicate that we handle the         WM_DELETE client message from the window manager, so that it won't         kill our window (and our app) along with it. Handle ClientMessage,
        post an error on the bus, and close the window. Further buffers
        arriving will result in a FlowError because the window has been

        Fixes: #393975

The behaviour still looks a little strange, because gstreamer-properties doesn't seem to be handling errors on the bus. The test pattern window disappears when closed, but the throbber dialog stays open until it is explicitly closed too. That wouldn't happen if gstreamer-properties caught the error message and closed the window.
Comment 10 Ronald Bultje 2007-05-17 17:45:02 UTC
It is kind of weird that you close the bug if the testcase still doesn't behave as defined.

Maybe you should open a new bug in gnome-media so that this will be addresses, also?
Comment 11 Jan Schmidt 2007-05-18 08:23:24 UTC
The 'testcase' of gst-launch-0.10 videotestsrc ! ximagesink works perfectly - when the window is closed, it receives an error on the bus that causes it to shut down cleanly.

Feel free to open a gnome-media bug if you have a burning desire to make gstreamer-properties handle errors too, but I won't be because it just feels like turd-polishing to me.