Re: [PyOpenGL-Users] glutInitDisplay segfault in python, but works in C++

[Duong D. <dan...@gm...>]

On Thu, Feb 24, 2011 at 3:33 AM, Alejandro Segovia <as...@gm...> wrote:
> Dear Sovannara,
>
> On Wed, Feb 23, 2011 at 3:03 PM, Sovannara Hak <hak...@gm...>
> wrote:
>>
>> Hello,
>> I ran gdb on the hello.py using Ubuntu 10.04 and intel graphic card
>> (There was no problem with the same computer in fedora 12.)
>> (gdb) r
>> Starting program: /usr/bin/python hello.py
>> [Thread debugging using libthread_db enabled]
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x004fb256 in glGetError () from /usr/lib/mesa/libGL.so.1
>> (gdb) bt
>> #0  0x004fb256 in glGetError () from /usr/lib/mesa/libGL.so.1
>> #1  0x0049301f in ffi_call_SYSV ()
>>    from /usr/lib/python2.6/lib-dynload/_ctypes.so
>> #2  0x00492e4c in ffi_call () from
>> /usr/lib/python2.6/lib-dynload/_ctypes.so
>> #3  0x0048d48d in _CallProc () from
>> /usr/lib/python2.6/lib-dynload/_ctypes.so
>> #4  0x00484e1e in ?? () from /usr/lib/python2.6/lib-dynload/_ctypes.so
>> #5  0x0806245a in PyObject_Call ()
>> #6  0x080e0471 in PyEval_EvalFrameEx ()
>> #7  0x080e2807 in PyEval_EvalCodeEx ()
>> #8  0x0816b2ac in ?? ()
>> #9  0x0806245a in PyObject_Call ()
>> #10 0x0806a45c in ?? ()
>> #11 0x08066573 in PyObject_CallFunctionObjArgs ()
>> #12 0x00484f4a in ?? () from /usr/lib/python2.6/lib-dynload/_ctypes.so
>> #13 0x0806245a in PyObject_Call ()
>> #14 0x080e0471 in PyEval_EvalFrameEx ()
>> #15 0x080e2807 in PyEval_EvalCodeEx ()
>> #16 0x080e2907 in PyEval_EvalCode ()
>> #17 0x081005ad in PyRun_FileExFlags ()
>> #18 0x08100812 in PyRun_SimpleFileExFlags ()
>> #19 0x0805de5c in Py_Main ()
>> #20 0x0805d03b in main ()
>> it seems that the intel driver doesn't handle very well the glGetError()
>> called by glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB)
>> because there was no context at this point.
>> but if we put a glCreateWindow("hello") just before glutInitDisplay
>> the program doesnt segfault anymore.
>
> I'm glad you were able to find a workaround for this issue.
> I am not very familiar with GLUT, but I think normally glutInit should be
> the first function called, as it's the one that initializes the library. My
> guess is that for some reason glutInit is failing to initialize and when it
> tries to get the error message (using glError), then a segfault is produced
> because no valid OpenGL context is available.
> The reasons glutInit might fail include not supporting OpenGL on the system,
> not being able to connect to the window system (Xorg) or invalid command
> line options.
> In any case, maybe the Intel driver needs to have the window created first.
> Definitely weird... have you tried using pygame to create the window or do
> you *have* to use GLUT?
> Alejandro.-
>
>>


Hi Alejandro,

It is weird indeed since the hello.c program did work on the Itel card
without the workaround.

We also tried this simple program

#include <GL/gl.h>

int main(int argc, char* argv[]) {
  glGetError();
  return 0;
}

which runs ok on a nvidia but segfaults on the Intel card.

My guess is that the GL implementation on the Intel card requires a
proper context be created
 before calling glGetError. Somewhere in the python wrapper of
glutInitDisplayMode,
it calls glGetError and causes the segfaults on the Intel card since there
is no context.

We haven't try pygame but I think we're happy with the workaround
right now since we don't
want to add an extra dependency to our project.

Best,

Duong