Xpra: Ticket #894: 0.15.1 client error: do_paint_rgb32

Upgraded client to 0.15.1 (server is still 0.15.0), now client logs the following errors:

2015-06-19 20:12:37,296 do_paint_rgb32 error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/client/window_backing_base.py", line 303, in do_paint_rgb32
    success = (self._backing is not None) and self._do_paint_rgb32(img_data, x, y, width, height, rowstride, options)
  File "/usr/lib/python2.7/dist-packages/xpra/client/gtk2/pixmap_backing.py", line 85, in _do_paint_rgb32
    pixbuf = gdk.pixbuf_new_from_data(rgba, gtk.gdk.COLORSPACE_RGB, True, 8, width, height, rowstride)
TypeError: pixbuf_new_from_data() argument 1 must be string or read-only buffer, not bytearray

Client is started with --opengl=no. rencode + lz4; encoding rgb32...



Fri, 19 Jun 2015 10:55:14 GMT - Antoine Martin: status, summary changed

changing the bug title, as this was not changed in 0.15.1

That's with opengl=off. Anything else I should know to reproduce? (exact command line, application used, DE, etc..)


Fri, 19 Jun 2015 11:40:11 GMT - onlyjob:

I don't recall anything special... Attached with xpra attach ssh:hostname:22 --opengl=no and encoding = rgb24 in config file... I shall be happy to give some more specific details if you tell me what you need to know (dump by the Xpra bug report tool, etc.)...


Fri, 19 Jun 2015 11:41:29 GMT - onlyjob:

Application kmail (on server); desktop environment - Cinnamon (on client).


Fri, 19 Jun 2015 12:12:14 GMT - Antoine Martin: owner, status, summary changed

To hit do_paint_rgb32, I believe you need: a Linux client, opengl off, an application that claims to use transparency (many KDE apps do). So I've changed the title of the ticket back to what it was: 0.15.1 fixed transparency, so we may now hit this codepath whereas 0.15.0 did not!

I've just tried all sorts of applications, and cannot reproduce the problem, as usual. With and without mmap, transparency, etc..

Please provide more details, xpra info would be a good start. Are you compiling with --with-memoryview by any chance?

I believe that r9682 would fix this, and it should be safe to backport, but I am just not sure about why I am not hitting this bug when I test (and no-one else did during 0.15 beta testing either, and there are still a few blacklisted cards in 0.15 that must have been tested by afarr) - which makes me nervous.

btw, I assume you meant "rgb" and not "rgb32", as "rgb32" is an internal encoding, not one the user can select from the command line or tray.


Fri, 19 Jun 2015 12:24:38 GMT - onlyjob:

Few hours ago I upgraded server to 0.15.1 and haven't seen this error ever since... I'm not building with --with-memoryview -- should I? Is it a good idea to compile with --with-memoryview? What "memoryview" is for? Thanks.


Fri, 19 Jun 2015 12:46:11 GMT - Antoine Martin:

The server version -should- not matter, even a 0.14.x server should be able to trigger it. That said... things aren't always that simple, maybe it's a corner case with uncompressed data or something.

for memoryview, see #465. It is now the default in trunk (0.16), should be left untouched in 0.15 (though it should work out of the box, and may change the type of the pixel buffer in this case.. which could make this bug disappear)


Mon, 22 Jun 2015 10:13:09 GMT - onlyjob:

In session (0.15.1 to 0.15.1) running for three days this error appeared only twice.


Sun, 05 Jul 2015 08:52:29 GMT - psycho_zs:

For me the client spams these messages when apps trying to draw gtk2 or gtk3 menus. Qt menus are fine.

GTK Menus appear blank white. Sometimes they do draw, but further redraw is still lagging behind heavily.


Sun, 05 Jul 2015 08:54:07 GMT - Antoine Martin: owner changed

@psycho_zs: how do I reproduce?


Sun, 05 Jul 2015 09:16:08 GMT - psycho_zs:

Launch any gtk application and spawn any menu in it. I'm using Debian testing and xpra 0.15.2+dfsg-2 (from experimental)


Mon, 06 Jul 2015 11:54:22 GMT - Antoine Martin:

I've just tried in a virtualbox vm - which disabled opengl (does that make any difference for you?), and launching a simple example like this one: browser/xpra/trunk/src/tests/xpra/test_apps/test_drop_down.py and also gnome's "baobab". No problem. I've tried both xpra 0.15.2 from xpra.org and experimental, no difference.

@psycho_zs: please provide more details, does the packaging matter? (try xpra.org packages?, try install from source?), does opengl matter? mmap matter? encoding? etc as per wiki/ReportingBugs. Please name a (simple) specific application which triggers the problem.


Fri, 17 Jul 2015 10:21:45 GMT - Antoine Martin:

I do have a non-virtualized machine to test on now, and I've installed xpra-0.15.3-dfsg-1 from experimental on it. Tried with "baobab" as well as the test app from comment:11, still no problem.

Unless I can reproduce this bug with 0.15.3 or later, I will have to close as "invalid".


Sat, 18 Jul 2015 07:03:28 GMT - onlyjob:

Thanks for looking into this problem. I have nothing new to add and frankly the problem was not too annoying. I'm OK to close this ticket -- if it suddenly get worse we can always re-open unless somebody report it again...


Mon, 20 Jul 2015 17:07:41 GMT - Antoine Martin: status changed; resolution set

Unable to reproduce, so closing as needinfo.


Sat, 23 Jan 2021 05:09:04 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/894