Hi,
While I was studying OpenGL with Mesa, I got a problem concerning
glAreTexturesReside().
First, please skim the following small glut program, whose original
purpose is to illustrate how to do texture prioritization with
OpenGL API, though the prioritization is not the issue of this
note.
#include <GL/glut.h>
GLuint texture;
void init(void)
{
GLubyte pixel[] = { 0xff, 0xff, 0xff };
GLclampf priority = 1.0f;
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexImage2D(GL_TEXTURE_2D, 0, 3, 1, 1, 0,
GL_RGB, GL_UNSIGNED_BYTE, pixel);
glPrioritizeTextures(1, &texture, &priority);
glEnable(GL_TEXTURE_2D);
}
void display(void)
{
GLboolean residence = GL_FALSE;
glAreTexturesResident(1, &texture, &residence);
}
int main(int argc, char *argv[])
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_RGBA);
glutCreateWindow(argv[0]);
glutDisplayFunc(display);
init();
glutMainLoop();
return 0;
}
Do you see anything wrong with the code above? Actually,
it compiles. It works fine if direct rendering is enabled.
I found, however, it resulted in segfault when I did
$ LIBGL_ALWAYS_INDIRECT=1 ./prog
That's the problem I got.
Looking for the cause of the segfalut, I used gdb with
the core dumped. But it didn't give me any useful clue
for the cause because it only suggested that the value of
an internal variable of glut was invalid, which I thought
was irrelevant to the problem.
So, after tweaking the code above, I found:
(1) If the call of glAreTexturesResident() was removed,
segfault didn't take place.
(2) If either the scope or the storage type of 'residence',
which is a local variable of the function display(),
was changed to local static or global, segfalut didn't
take place. (In this case, the glAreTexturesResident
code was not removed.)
Since the fact (2) suggested that there was something wrong
with the stack or frame, I suspected it was due to a bug
of the compiler I used. But I soon came to realize that
it was fairly unlikely: the same problem arose even with
the binary compiled with gcc-2.95.3 or gcc-3.4.4, not only
with the latest gcc-4.0.2.
So I concluded, as the fact (1) suggested, that there was
something wrong with glAreTexturesResident(), to be more
specific, __indirect_glAreTexturesResident(), whose
implementation was given src/glx/x11/indirect.c.
At line 4306 of the file, the function
GLboolean
__indirect_glAreTexturesResident(GLsizei n,
const GLuint *textures,
GLboolean *residences);
is defined. Unless USE_XCB is defined, the function invokes
CARD32
__glXReadDisplay(Display *dpy,
size_t size,
void *dest,
GLboolean reply_is_always_true);
with the parameters size = 1, dest = residences, and
reply_is_always_true = GL_TRUE.
The implementation of __glXReadDisplay() is given at line 66
of the same file. The following is the excerpt of the
implementation:
xGLXSingleReply reply;
_XReply(dpy, &reply, 0, False);
if (size != 0) {
if ((reply.length > 0) || reply_is_always_true) {
const GLint bytes = (reply_is_always_array)
? (4 * reply.length) : (reply.size * size);
...
_XRead(dpy, dest, bytes);
...
}
...
}
Since size = 1, and reply_is_always_true = GL_TRUE in our
particular case, the value of the local variable 'bytes' is
equal to that of 4 * reply.length if reply.length > 0. This
implies that we let _XRead() write the reply from the server
to the parameter 'dest' as if the storage size 'dest' points
to were at least 4 bytes, which is wrong in our particular
case where 'dest' is actually a pointer to a variable of type
GLboolean.
I think this caused the segfault I mentioned in the middle
of this note. It also seemingly explains the "undefined
behavior"-like phenomenon, i.e., the fact (2).
It looks to me that the implementation of __glXReadDisplay()
is valid only for the case where the parameter 'size' is set
to 4. IOW, the case for 'size' = 1, 2 is not appropriately
supported.
Did I miss something?
Thanks,
KK
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
