Re: [VirtualGL-Devel] XCB Support Notes

[DRC <dco...@us...>]

Please check out the code in SVN trunk and see if it corrects this 
issue.  VGL now aggressively disables its XCB interposer whenever any 
"real" XCB, X11, or GLX symbol is called, so that should (unless I miss 
my guess) guard against any instances of "double interposing."  Within 
VirtualGL, there are basically three versions of an interposed function:

	function() -- the interposed version
	_function() -- a wrapper that verifies that the "real" function symbol 
exists and is loaded, then invokes the "real" function
	__function() -- the "real" function

I modified the wrappers such that they increment a thread-local counter 
variable (fakerLevel) before calling the "real" function and decrement 
the same variable whenever the "real" function returns.  All of the 
interposed XCB functions will now pass through to the "real" XCB 
function, without modification, whenever fakerLevel is non-zero.  Unless 
I miss my guess, this should prevent the XCB interposer from activating 
unless an application explicitly calls one of the interposed XCB functions.

Additionally, VGL has been modified such that you now have to explicitly 
enable XCB interposition by setting VGL_FAKEXCB=1 or passing +xcb to vglrun.


On 11/25/14 9:31 PM, Nathan Kidd wrote:
> On 24/11/14 12:23 PM, DRC wrote:
>> I think it might be prudent to enable it only with a 'vglrun +xcb'
>> switch or something like that. I just predict that this is not the
>> last we've heard of issues like this.
>
> Oooh, here's a nice one:
>
> xcb_get_extension_data doesn't just say "Yes I have GLX".  It also
> returns the extension major opcode that xcb_send_request uses for the io
> vector index.  So when the VGL_PROBEGLX code does its thing we get:
>
> #0  XGetXCBConnection (dpy=0x608620) at x11_xcb.c:9
> #1  0x00007ffff78d23b6 in _XGetXCBConnection (dpy=0x608620) at
> /home/nathan/src/virtualgl/server/faker-sym.h:529
> #2  0x00007ffff78e97e9 in xcb_get_extension_data (conn=0x61a3a0,
> ext=0x7ffff5b90050 <xcb_glx_id>)
>      at /home/nathan/src/virtualgl/server/faker-xcb.cpp:149
> #3  0x00007ffff55607d8 in xcb_send_request (c=c@entry=0x61a3a0,
> flags=flags@entry=1,
>      vector=vector@entry=0x7fffffffda50, req=req@entry=0x7ffff5b8f950
> <xcb_req.12371>) at xcb_out.c:177
> #4  0x00007ffff59850b2 in xcb_glx_query_server_string
> (c=c@entry=0x61a3a0, screen=screen@entry=0,
>      name=name@entry=2) at glx.c:2375
> #5  0x00007ffff76a057e in __glXQueryServerString
> (dpy=dpy@entry=0x619150, opcode=<optimized out>,
>      screen=screen@entry=0, name=name@entry=2) at glx_query.c:47
> #6  0x00007ffff7682dd6 in AllocAndFetchScreenConfigs (priv=0x679dc0,
> dpy=0x619150) at glxext.c:764
> #7  __glXInitialize (dpy=dpy@entry=0x619150) at glxext.c:879
> #8  0x00007ffff767f71b in GetGLXPrivScreenConfig (dpy=0x619150, scrn=0,
> ppriv=ppriv@entry=0x7fffffffdb20,
>      ppsc=ppsc@entry=0x7fffffffdb28) at glxcmds.c:174
> #9  0x00007ffff767f7ab in GetGLXPrivScreenConfig (ppsc=0x7fffffffdb28,
> ppriv=0x7fffffffdb20,
>      scrn=<optimized out>, dpy=<optimized out>) at glxcmds.c:170
> #10 glXGetConfig (dpy=<optimized out>, vis=0x631630, attribute=5,
> value_return=0x63a1b8) at glxcmds.c:880
> #11 0x00007ffff78fd498 in _glXGetConfig (dpy=0x619150, vis=0x631630,
> attrib=5, value=0x63a1b8)
>      at /home/nathan/src/virtualgl/server/faker-sym.h:178
> #12 0x00007ffff78fddf8 in buildVisAttribTable (dpy=0x619150, screen=0)
>      at /home/nathan/src/virtualgl/server/glxvisual.cpp:131
> #13 0x00007ffff78fee96 in __vglMatchVisual (dpy=0x619150, screen=0,
> depth=24, c_class=4, level=0, stereo=0,
>      trans=0) at /home/nathan/src/virtualgl/server/glxvisual.cpp:354
> #14 0x00007ffff78dc484 in glXChooseVisual (dpy=0x619150, screen=0,
> attrib_list=0x7fffffffdf00)
>      at /home/nathan/src/virtualgl/server/faker-glx.cpp:424
> #15 0x0000000000405909 in main (argc=2, argv=0x7fffffffe078)
>      at /home/nathan/src/virtualgl/glxdemos/glxspheres.c:602
> (gdb) c
> Continuing.
> [VGL] !!! Replaced xcb connection 0x61a3a0 with 0x609950 from
> xcb_get_extension_data
> Breakpoint 7, xcb_glx_query_server_string_string_length (R=R@entry=0x0)
> at glx.c:2448
> 2448	glx.c: No such file or directory.
> (gdb) c
> Continuing.
> Program received signal SIGSEGV, Segmentation fault.
> xcb_glx_query_server_string_string_length (R=R@entry=0x0) at glx.c:2448
>
> I.e.  xcb_glx_query_server_string fails because the data tries to send
> on wrong iovector, and glXQueryServerString isn't prepared to handle a
> failure.
>
> This is on an OpenSuSE 13.1 box with Mesa 9.x + Nouveau, and doesn't
> happen on modern Mesa or with NVIDIA's binary, but it demonstrates the
> pitfalls of hooking an API that is used by the underlying
> implementation, not just applications.
>
> Ways I can think of to work around this:
>
> 1) just disallow any non-3D-server GLX traffic, and loose the
> VGL_PROBEGLX benefits.  Hmmm, this looks like it kills the possibility
> of stereo support, though I've never seen a stereo user.
>
> 2) Introduce a global (TLS-based should work) don't-fake-xcb-for-now
> flag that the VGL_PROBEGLX code sets and the XCB hooks honour.
>
>
> -Nathan
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> VirtualGL-Devel mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>