xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 7 years ago

Closed 7 years ago

Last modified 16 months ago

#929 closed defect (fixed)

opengl exception: access violation reading 0x0BDD0000

Reported by: alas Owned by: Antoine Martin
Priority: critical Milestone: 0.16
Component: android Version: 0.15.x
Keywords: Cc:


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.

Change History (6)

comment:1 Changed 7 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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.

comment:2 Changed 7 years ago by Antoine Martin

Summary: Trying to run pycallgraph profiling, ran into a tracebackopengl exception: access violation reading 0x0BDD0000

(editing title)

comment:3 Changed 7 years ago by Antoine Martin

Priority: majorcritical

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

Can you still reproduce this bug?

comment:4 Changed 7 years ago by alas

Owner: changed from alas to Antoine Martin

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

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 7 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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

comment:6 Changed 16 months ago by migration script

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

Note: See TracTickets for help on using tickets.