opengl exception: access violation reading 0x0BDD0000

[totaam]

Issue migrated from trac ticket # 929

component: android | priority: critical | resolution: fixed

2015-07-29 03:12:41: afarr created the issue

---

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.

[totaam]

2015-07-29 03:20:10: antoine changed owner from antoine to afarr

[totaam]

2015-07-29 03:20:10: antoine commented

---

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.

[totaam]

2015-07-29 03:21:04: antoine changed title from Trying to run pycallgraph profiling, ran into a traceback to opengl exception: access violation reading 0x0BDD0000

[totaam]

2015-07-29 03:21:04: antoine commented

---

(editing title)

[totaam]

2015-08-19 06:29:53: antoine changed priority from major to critical

[totaam]

2015-08-19 06:29:53: antoine commented

---

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

Can you still reproduce this bug?

[totaam]

2015-09-16 00:29:04: afarr changed owner from afarr to antoine

[totaam]

2015-09-16 00:29:04: afarr commented

---

Tested again with 0.16.0 r10624 client (windows) side and server (fedora 21) side (and also with 0.15.6 10639 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.)

[totaam]

2015-09-16 04:06:08: antoine changed status from new to closed

[totaam]

2015-09-16 04:06:08: antoine set resolution to fixed

[totaam]

2015-09-16 04:06:08: antoine commented

---

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