[Octave-bug-tracker] [bug #44478] test __osmesa_print__.cc-tst crashes with Nvidia drivers

[Dan Sebald]

Follow-up Comment #96, bug #44478 (project octave):

Good guess Rik.  Here's -lOSMesa first (reports 16 for depth) followed by
-lOSMesa second (reports 0 for depth):


sebald@ ~/octave/opengl_nvidia $ g++ osmesa-foo-mod.cc -lOSMesa -lGL
sebald@ ~/octave/opengl_nvidia $ a.out
CTX: 0x7f64cf35c010
GL_DEPTH_BITS: 16
GL_STENCIL_BITS: 0
sebald@ ~/octave/opengl_nvidia $ g++ osmesa-foo-mod.cc -lGL -lOSMesa
sebald@ ~/octave/opengl_nvidia $ a.out
CTX: 0x7ff768d7e010
GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 0


Of course, the worry would be that this linking in Octave might cause nVidia
OpenGL to act flaky, which could be a worse problem.

I'm looking at the innards of OSMesa at the moment.  In particular
OSMesaMakeCurrent().  One thing I notice is there is this line:


   _mesa_make_current( &osmesa->mesa, osmesa->gl_buffer, osmesa->gl_buffer );


in a string of commands pertaining to frame buffer resizing and stuff.  At the
end of this string of function calls and code is


   return GL_TRUE;


But, that _mesa_make_current() returns a Boolean, so I can see now how the
_mesa_make_current() can fail and the function OSMesaMakeCurrent() still
indicates success.  That might explain how we can see


GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 0


rather than getting the


    error ("__osmesa_print__: OSMesaMakeCurrent failed!");


error message.

Other observations are that the OSMesa has a lot of commands pertaining to
multi-threading.

Well, anyway, so why this order of linking matters?  All I can think of right
now is that there seem to be a lot of variables and such apparently common to
both the -lGL and -lOSMesa drivers, judging from the contents of the "nm"
dumps I did on the two libraries.  It takes some investigation to tell exactly
what's happening and how these are all linked together.  For example, some
entries are in the text space "T" in one module, but undefined "U" in the
other module.  But there are some that are present in both:


000000000004ba00 T _glapi_create_table_from_handle



000000000028b2c0 T _glapi_create_table_from_handle


I wonder if there might be a handful of variables and/or functions that are
the same in the source code for the two libraries and are interfering with
proper behavior.  Rik, we probably should find some linking switch for
uniqueness of global names in the object code, if just to help diagnose.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44478>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/