GNOME Bugzilla – Bug 634815
[xvimagesink] Catch and handle X11 errors and don't pass them to GDK/etc
Last modified: 2013-12-04 21:14:41 UTC
Created attachment 174429 [details] backtrace This was originally reported to Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=562238 The problem is that when the machine is suspended while playing a movie, totem will crash upon resume. The fedora bug contains the abrt backtrace, I am attaching one obtained with pure gdb. There was an error about X sync stuff, so if you cannot reproduce the issue please tell me how to solve that problem. The issue happens with audio files with visualisation enabled, but with visualisation off playing the audio file becomes resume-safe.
Looks like a GStreamer bug with the visualisations, then. What GStreamer core and plugins versions do you have? Pasting the stacktrace inline so it's searchable:
+ Trace 224661
Not only visualisations since it crashes on movies as well. When it comes to versions, I have versions from up-to-date Fedora 14 + RPM Fusion. I'll be more specific when I get home.
$ rpm -qa | grep gstreamer | sort bluez-gstreamer-4.77-1.fc14.x86_64 gstreamer-0.10.30-1.fc14.i686 gstreamer-0.10.30-1.fc14.x86_64 gstreamer-debuginfo-0.10.30-1.fc14.x86_64 gstreamer-devel-0.10.30-1.fc14.x86_64 gstreamer-ffmpeg-0.10.11-1.fc14.x86_64 gstreamermm-0.10.8-1.fc14.x86_64 gstreamer-plugins-bad-0.10.20-2.fc14.x86_64 gstreamer-plugins-bad-free-0.10.20-3.fc14.x86_64 gstreamer-plugins-bad-free-extras-0.10.20-3.fc14.x86_64 gstreamer-plugins-bad-nonfree-0.10.18-1.fc13.x86_64 gstreamer-plugins-base-0.10.30-2.fc14.i686 gstreamer-plugins-base-0.10.30-2.fc14.x86_64 gstreamer-plugins-base-debuginfo-0.10.30-2.fc14.x86_64 gstreamer-plugins-base-devel-0.10.30-2.fc14.x86_64 gstreamer-plugins-good-0.10.25-1.fc14.x86_64 gstreamer-plugins-ugly-0.10.16-2.fc14.x86_64 gstreamer-python-0.10.19-1.fc14.x86_64 gstreamer-rtsp-0.10.5-2.fc14.x86_64 gstreamer-tools-0.10.30-1.fc14.x86_64 PackageKit-gstreamer-plugin-0.6.9-4.fc14.x86_64
OK, this is strange. If I ask to break at gdk_x_error and run totem with --sync [1], it survives the resume. The --sync alone is not enough. [1] http://wiki.debian.org/HowToGetABacktrace#DebuggingXErrors
I just realised you don't actually need to sleep, it is enough to switch to tty2 (which I have running in vga=0x318) and back.
Does this also happen with non-gstreamer based movie players like VLC or Xine when using XV?
VLC with XVideo (XCB) output survives both vt switch and resume. Ditto mplayer, but it shows the following in the console (many times): X11 error: BadAlloc (insufficient resources for operation)
Ok, so xvimagesink should probably catch X11 errors like BadAlloc and somehow and don't get them handled by the GDK (or whatever) X11 error handlers
Oh joy. This is the "gdk steals our X errors" bug. There's not much we can do about this until we switch to xcb. Xlib only has one global error handler per process, which obviously goes to gdk. We can only try really hard to not generate errors.
So... what stops us from switching to xcb ?
Reopening as I don't see any open non developer issue
From a recent discussion on IRC about this, I understand the switch to XCB will likely never happen (not even desired from what I understood). Shall we close this one as a WONTFIX ?
Let's wontfix this. The most important X apps (Empathy, Totem) used Clutter/OpenGL now anyway.