octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #44478] test __osmesa_print__.cc-tst crashes w


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #44478] test __osmesa_print__.cc-tst crashes with Nvidia drivers
Date: Thu, 12 May 2016 00:42:32 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

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

On second thought, looking at these results from the object file list:


000000000006a1c0 T glGetIntegerv
000000000006a1e0 T glGetLightfv
000000000006a200 T glGetLightiv


makes me think these aren't the actual functions.  Although the 'T' means code
space, there's only 32 bytes distance between the glGetIntegerv and
glGetLightfv.  That makes me think these are entries in a table.  The OpenGL
standard indicates the glXYZ functions do not exist until there is a valid
context.

To test this theory, I've run JWE's minimal program--without the -lGL library
linked in--and did not create an OSMesa context.  It segfualts.  So... doing


  OSMesaContext ctx = OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, NULL);


indicates it is creating a valid context.  And in this bare-bones example


  glGetIntegerv (GL_DEPTH_BITS, &z);
  glGetIntegerv (GL_STENCIL_BITS, &s);


does not crash.  So, OK, then perhaps OSMesa is operating correctly and the
OpenGL routines are getting mapped into the space.

BUT, when the -lGL library is nVidia, the result of the above two lines is no
action (i.e., z and s come back unchanged).

Let's try then commenting out this line:


  // Bind the buffer to the context and make it current.
//  if (! OSMesaMakeCurrent (ctx, buffer, GL_UNSIGNED_BYTE, Width, Height))
//    error ("__osmesa_print__: OSMesaMakeCurrent failed!");


and see how that runs when -lGL is not linked in...  Does not crash, but comes
back:


sebald@ ~/octave/opengl_nvidia $ a.out
CTX: 0x7f3b83744010
GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 0


Interesting, so it could be OSMesaMakeCurrent() that is failing.  I'll look at
the source code to see what it is doing.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]