[Mesa-dev] Mismatch between Mesas dispatch table and the one used by the X server

[Stefan Brüns]

On Tuesday 12 March 2013 09:25:07 Ian Romanick wrote:
> On 03/10/2013 11:24 AM, Stefan Brüns wrote:
> > Hi everyone,
> > 
> > I have run into a problem leading to a crashing X server for a bunch of
> > indirect GLX calls.
> > 
> > This problem affects any OpenGL clients using indirect rendering and
> > calling functions which are outside the ABI. Problems range from
> > malfunctioning to crashes.
> > 
> > Problem analysis:
> > 
> > The dispatcher functions in glx/indirect_dispatch.c demarshall the
> > function
> > arguments from the GLX wire protocol and then call the appropriate
> > function of the GL library. Function calls are done using dispatch table
> > with the help of the CALL_* helper macros defined in dispatch.h.
> > 
> > Unfortunately there is a mismatch between the dispatch table expected by
> > the xserver - which follows the layout e.g. found in glapitable.h - and
> > the one provided by the GL library, e.g. Mesa.
> 
> The dependency is the other way around.  The loader (either libGL on the
> client or the GLX extension in the server) dictates the layout of the
> dispatch table.  The GL driver is required to adapt to the layout
> dictated by the loader.  That's the whole reason the remap table exists.
>   The driver queries the loader to learn where functions are located in
> the dispatch table.  It then stores the dispatch table locations at
> (fixed) locations in the remap table.  So, the driver knows that glFoo
> is at location 824 in the remap table, and that entry stores the
> location of glFoo in the dispatch table.
> 
> It sounds like something else is going wrong.

Currently this obviously can not work.

The remap table is only used when FEATURE_remap_table is defined, which for 
the X server is never true.

Now, lets try defining FEATURE_remap_table for the xserver (which breaks OS X 
and windows builds of Mesa, but anyway ...)

Even then, the lookup of indexes for the remap table is going wrong.

The xserver uses the remap table slots defined in the dispatch.h exported from 
some past version of Mesa, i.e. "#define TexBufferARB_remap_index 174".

Now the remap table is populated from _mesa_init_remap_table in 
mesa/main/remap.c, which calls:
_mesa_do_init_remap_table(_mesa_function_pool,
driDispatchRemapTable_size, MESA_remap_table_functions);

Now lets have a look a look into MESA_remap_table_functions[174], which should 
have the entry for TexBufferARB, and yes, its there, so everything fine!

But wait, do another test - ClientWaitSync, slot 178 in remap table, at least 
if you ask the x server, but slot 185 if you ask Mesa ...

So obviously the remap table is filled with the wrong values.

Regards, Stefan


-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
phone: +49 241 53809034     mobile: +49 151 50412019