TLS support is spotty on non-Linux platforms, unfortunately.  Why 
couldn't we just use the existing XCB connection hash to maintain an 
"enabled" state for the XCB faker?  Whenever an interposed GLX or X11 
function is called, VGL will attempt to find the XCB connection 
corresponding to the Display* argument.  If successful, VGL will set a 
"disable" bit for that connection, then re-enable it before returning 
from the interposed function.  Then the interposed XCB functions can 
look up the connection in the hash and make sure it has interposing 
enabled before proceeding.


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
> VirtualGL-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>

------------------------------------------------------------------------------
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
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

Reply via email to