Closed totaam closed 10 years ago
is this still occurring with 0.10 and latest drivers? Does using/turning-off opengl make any difference?
Not heard back, closing. Feel free to re-open.
When time allows I do my best to answer in timely fashion. Turning OpenGL off completely helps a little but crash still happening if window resized for few seconds.
I didn't have time to test 0.10 yet. In worst case I'll try it when released. I don't want to re-open right away but I've seen no evidence of this fixed yet. Do you have reasonable expectations that this problem is gone? Perhaps you could gently remind without closing...
This is probably not fixed at our end, which is why I closed it as
needinfo
.[[BR]]
There were fixes all over, some of which may prevent this crash, but since this really looks like a driver bug (no client application should be able to crash the X11 server - even badly behaved ones), you should probably take this bug upstream (
fglrx
).
I wish taking this upstream would be easier... There are number of bugs that might be more or less related to this issue:
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698008
- https://bugs.freedesktop.org/show_bug.cgi?id=57534
- http://ati.cchtml.com/show_bug.cgi?id=687
- http://ati.cchtml.com/show_bug.cgi?id=633
- http://ati.cchtml.com/show_bug.cgi?id=567
- http://ati.cchtml.com/show_bug.cgi?id=657
- https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1151242
But I reckon the difficult part is to reliably reproduce it which I can't do without Xpra...
For the record, 0.10.x are affected as well, there were no difference in that regards...
Does this help? Run the client with
XPRA_BACKING_COPY="0" xpra attach --opengl=off ...
--- src/xpra/client/gtk2/pixmap_backing.py (revision 4326) +++ src/xpra/client/gtk2/pixmap_backing.py (working copy) @@ -4,6 +4,7 @@ # Xpra is released under the terms of the GNU GPL v2, or, at your option, any # later version. See the file COPYING for details. +import os import gtk from gtk import gdk import cairo @@ -12,7 +13,9 @@ log = Logger() from xpra.client.gtk2.window_backing import GTK2WindowBacking +BACKING_COPY = os.environ.get("XPRA_BACKING_COPY", "1")=="1" + """ Backing using a gdk.Pixmap """ @@ -36,6 +39,8 @@ self._has_alpha = False else: self._backing = gdk.Pixmap(gdk.get_default_root_window(), w, h) + if not BACKING_COPY: + return cr = self._backing.cairo_create() cr.set_source_rgb(1, 1, 1) if old_backing is not None:
If so, I may be able to create a smaller reproducible test case.
A lifesaver. :)
XPRA_BACKING_COPY "fixed" it (in a workaround manner). I also tried tested it with opengl and after many resizes that would usually terminate X I got segfault in xpra-client (but X survived).
I don't understand the implications of that change but I'm tempted to ask you for its temporary inclusion. I lost count of how many times I had X crashed (and time lost) so this workaround is very valuable for me. Thank you.
This tells me that the bug is probably in the pixmap readback code in the fglrx driver. When the window is resized, we copy the old pixmap (old size) onto the new one so that we have something to show and paint with before we get the new frame from the server. The pixmap is an off-screen resource and should still be valid until we dispose of it explicitly.
I'll try to make a sample standalone GTK app to crash your X11 server, hopefully this will force ATI/AMD to fix their driver. In the meantime, r4355 applies the workaround from comment:7 with only a minor change (paint the new pixmap white rather than leaving it uninitialized).
Thanks, the test case is awesome as it crashes X reliably. :)
So far I've sent it to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698008 -- hopefully someone will pass it further.
So with 4583 xpra won't be crashing Xorg any more, right? I'll try to test later this week.
Works fine here, closing. (and let's hope AMD fix this - API misuse or not, crashing the X11 server isn't user friendly!)
Issue migrated from trac ticket # 327
component: client | priority: major | resolution: fixed
2013-04-27 13:35:01: onlyjob created the issue