I've tracked this down to the following two:

XSync (ximagesink->xcontext->disp, FALSE);

Around line 290 in ximagesink.c, gst_ximagesink_ximage_put (). From
man XSync: "Client applications seldom need to call XSync." Why do we
use it? Is it hiding other bugs? Anyway, I commented it out, and then
got (seems to take quite a few more resizes to crash, but still)
crashes in:

XGetWindowAttributes (ximagesink->xcontext->disp,
                        ximagesink->xwindow->win, &attr);

around line 410 in ximagesink.c,
gst_ximagesink_xwindow_update_geometry (). I'm not sure why. The
XWindowID didn't change.

Anyway, all this reminds me that we need an error handler in
ximagesink and xvimagesink that calls GST_ELEMENT_ERROR() instead of
just crashing. See man XSetErrorHandler.

XSetErrorHandler() isn't useful, since it's global to Xlib, not tied
to a particular file descriptor.  Thus, ximagesink setting an error
handler will interfere with gdk's.

Given the error messages I'm guessing that somehow, even though I set
synchronous to true, it doesn't run in synced-mode. It's simply the
XShmPutImage() before it.

And well, we'll have to figure out something else then, maybe call the
old handler from our new one or so (I'm quite sure gtk does that too,
will check some day)... But simply aborting isn't really a good thing
either.

The only XSync call in ximagesink.c that seems appropriate is on line
112, just before XSetErrorHandler().

I'd like to hear from dolphy why the others might be necessary.  Also,
the sync flag is not handled correctly.

Well i thought it was necessary to call XSync after each call supposed to
trigger some changes on the server...

I might check again the specifications for that...

I ve been looking at the documentation and XSync calls are maybe not really
needed in that case. Although they are completely harmless and i don't think
that might cause any crash..

Should we close that bug ? Do you still see a non expected behaviour ?

Yes I still see it. Close bugs when they're fixed, not anytime else. Please let
me know if you can reproduce it.

The XSync() calls are indeed harmless, they were a first impression of where the
bug might come from. They do make behaviour non-ideal, though, because you do
manual optimizing which is ususally not the optimal way of doing stuff. I'd
still vote for removing them. Note, however, that this is irrelevant w.r.t. this
bug and should therefore be discussed elsewhere.

I *think* (but cannot test or proove) that the crashes come from async resizes
to the X server and then us trying to upload a larger image than the server has
currently configured internally to it. That breaks, X sends an error back and we
crash as a result. I don't know how to fix it, I don't want to touch ximagesink
right now. It's written nicely, but I have other priorities, unfortunately.

XSync() is useful if you want to make sure your call has succeeded.  Given how
the X sinks work it is not very harmful in most cases since they aren't called
on every chain.

I'm currently going through the sinks adding error checking for all calls and
trying to trigger all instances of these errors people are ssing.

Ronald do you still have the problem ? I have done some modifications in the
image allocation code. I can't reproduce the bug here...

thanks,

Yes, appears fixed now. Thanks.