Running with server fedora 21 0.16.0 r9562 (svn update indicates as 10107 ... not sure why my version isn't indicating this in session info) against windows 8.1 client 0.16.0 r10002...
Running ./tests/scripts/pycallgraph -d 10 -I "*rectangle*,*encoding*,*.damage,*.do_send_delayed_regions,*.make_data_packet_cb,*._refresh_region,*.add_refresh_region" -- start :10 --no-notifications --no-daemon --start-child=xterm --no-mdns --no-pulseaudio --bind-tcp=0.0.0.0:1201 --start-child=xterm
in an attempt to blindly tweak profiling options, I wound up running into the following traceback server-side:
2015-07-28 17:05:24,489 gtk2.GLWindowBacking(3, (1029, 1000), YUV444P).gl_paint_planar(..) error: exception: access violation reading 0x0BDD0000 Traceback (most recent call last): File "xpra\client\gl\gl_window_backing_base.pyc", line 695, in gl_paint_planar File "xpra\client\gl\gl_window_backing_base.pyc", line 749, in update_planar_textures File "latebind.pyx", line 32, in OpenGL_accelerate.latebind.LateBind.__call__ (c:\Users\mcfletch\OpenGL-dev\OpenGL-ctypes\OpenGL_accelerate\src\latebind.c:989) File "wrapper.pyx", line 311, in OpenGL_accelerate.wrapper.Wrapper.__call__ (c:\Users\mcfletch\OpenGL-dev\OpenGL-ctypes\OpenGL_accelerate\src\wrapper.c:6439) WindowsError: exception: access violation reading 0x0BDD0000
The browser window also seemed to turn various shades of aqua... like a browser developer tool gone amok... which I assume was related tot he traceback, but not certain.
This is a client side error which is being forwarded to the server, you must have log forwarding enabled. You should be able to reproduce this without the profiling hooks.
Please include the full version info, as found in the bug report tool.
(editing title)
There were fixes in trunk for buffer handling which may have fixed this. In particular: r10172 and r10230.
Can you still reproduce this bug?
Tested again with 0.16.0 r10624 client (windows) side and server (fedora 21) side (and also with 0.15.6 r10639 server side).
Couldn't reproduce that bug.
One of my initial tests though, I tried to connect the client before the trace had started, and got a lot of sound pipeline errors (which I judge to be my fault for connecting while the trace was prepping, but I note in case anyone else makes the same mistake):
2015-09-15 16:04:58,248 sound-source pipeline warning: ["gstbaseaudiosrc.c(840): \ gst_base_audio_src_create (): /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:\n Dropped 1048520 samples. This is most likely because downstream can't keep up and is consuming samples too slowly."]
In one of the tests, when I stopped the server (xpra stop :10
), I did get this error message (which didn't seem to have any effect, but wasa menacing red pair of lines:
2015-09-15 16:22:09,918 unknown or invalid packet type: damage-sequence from Protocol(tcp socket: 10.0.32.136:1201 <- 10.0.11.137:50309)
I assume neither of these is of great issue. Looks like this can be closed, to me. (I'll reassign to you.)
The sound "dropped samples" warning is harmless and caused by pycallgraph slowing things down considerably. This is unlikely to happen any other way.
The "invalid packet" warning is a race (the "damage-sequence" was processed whilst we're closing down the connection), r10644 should make it less likely to show up - not that we should really worry too much about warnings during shutdown.
Closing.
PS: those tickets are a bit similar and worth linking here: #924, #901
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/929