Xpra: Ticket #929: opengl exception: access violation reading 0x0BDD0000

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

Wed, 29 Jul 2015 02:20:09 GMT - Antoine Martin: owner changed

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.

Wed, 29 Jul 2015 02:21:04 GMT - Antoine Martin: summary changed

(editing title)

Wed, 19 Aug 2015 05:29:52 GMT - Antoine Martin: priority changed

There were fixes in trunk for buffer handling which may have fixed this. In particular: r10172 and r10230.

Can you still reproduce this bug?

Tue, 15 Sep 2015 23:29:04 GMT - alas: owner changed

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

I assume neither of these is of great issue. Looks like this can be closed, to me. (I'll reassign to you.)

Wed, 16 Sep 2015 03:06:08 GMT - Antoine Martin: status changed; resolution set

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.


PS: those tickets are a bit similar and worth linking here: #924, #901

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

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