0.15.1 client error: do_paint_rgb32

[totaam]

Issue migrated from trac ticket # 894

component: client | priority: minor | resolution: needinfo

2015-06-19 11:25:15: onlyjob created the issue

---

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...

[totaam]

2015-06-19 11:55:14: antoine changed status from new to assigned

[totaam]

2015-06-19 11:55:14: antoine changed title from 0.15.1 client error: do_paint_rgb32 to 0.15.x client error: do_paint_rgb32

[totaam]

2015-06-19 11:55:14: antoine commented

---

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..)

[totaam]

2015-06-19 12:40:12: onlyjob commented

---

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.)...

[totaam]

2015-06-19 12:41:30: onlyjob commented

---

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

[totaam]

2015-06-19 13:12:15: antoine changed status from assigned to new

[totaam]

2015-06-19 13:12:15: antoine changed owner from antoine to onlyjob

[totaam]

2015-06-19 13:12:15: antoine changed title from 0.15.x client error: do_paint_rgb32 to 0.15.1 client error: do_paint_rgb32

[totaam]

2015-06-19 13:12:15: antoine commented

---

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.

[totaam]

2015-06-19 13:24:38: onlyjob commented

---

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.

[totaam]

2015-06-19 13:46:11: antoine commented

---

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)

[totaam]

2015-06-22 11:13:10: onlyjob commented

---

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

[totaam]

2015-07-05 09:52:29: psycho_zs commented

---

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.

[totaam]

2015-07-05 09:54:08: antoine changed owner from onlyjob to psycho_zs

[totaam]

2015-07-05 09:54:08: antoine commented

---

@psycho_zs: how do I reproduce?

[totaam]

2015-07-05 10:16:08: psycho_zs commented

---

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

[totaam]

2015-07-06 12:54:22: antoine commented

---

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 ReportingBugs.
Please name a (simple) specific application which triggers the problem.

[totaam]

2015-07-17 11:21:45: totaam commented

---

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".

[totaam]

2015-07-18 08:03:29: onlyjob commented

---

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...

[totaam]

2015-07-20 18:07:41: totaam changed status from new to closed

[totaam]

2015-07-20 18:07:41: totaam set resolution to needinfo

[totaam]

2015-07-20 18:07:41: totaam commented

---

Unable to reproduce, so closing as needinfo.