When the default python version in testing changed to 2.5 I found a program I had written failed with
segmentation faults. I've narrowed down the bug. The following is the smallest reasonable piece of
code which will cause the segfault:

from OpenGL.GLUT import *
glutInit(["appname"])
glutInitDisplayMode(GLUT_RGB)
glutInitWindowSize(640, 480);
glutCreateWindow("appname")

def disFunc():
    print "disFunc"

def keyFunc(*args):
    print "keyFunc"

glutDisplayFunc(disFunc)
glutKeyboardFunc(keyFunc)
glutMainLoop()


Pasting the code into python interactive mode demonstrates the problem as well as using a .py file.
Python will segfault as soon as it enters the glutMainLoop function. If either glutDisplayFunc(disFunc)
or glutKeyboardFunc(keyFunc) is commented out, there is no problem, and things behave as you would
expect them to. Also if I use python2.4, there is no problem. But if I use both keyFunc and disFunc
in python2.5: SIGSEGV, every time.

I'm not sure if a gdb backtrace is useful, but here it is, anyway:
#0  0x00002aaaabac5fcc in ?? ()
#1  0x00002aaaab314e83 in ?? () from /usr/lib/libglut.so.3
#2  0x00002aaaab318059 in fgEnumWindows () from /usr/lib/libglut.so.3
#3  0x00002aaaab31570e in glutMainLoopEvent () from /usr/lib/libglut.so.3
#4  0x00002aaaab315b38 in glutMainLoop () from /usr/lib/libglut.so.3
#5  0x00002b3dceb76e74 in ffi_call_unix64 () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#6  0x00002b3dceb768bd in ffi_call () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#7  0x00002b3dceb7179a in _CallProc () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#8  0x00002b3dceb6b4ff in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#9  0x0000000000417c73 in PyObject_Call ()
#10 0x00000000004854ca in PyEval_EvalFrameEx ()
#11 0x0000000000489756 in PyEval_EvalCodeEx ()
#12 0x0000000000489872 in PyEval_EvalCode ()
#13 0x00000000004ab339 in PyRun_InteractiveOneFlags ()
#14 0x00000000004ab544 in PyRun_InteractiveLoopFlags ()
#15 0x00000000004ab64a in PyRun_AnyFileExFlags ()
#16 0x000000000041442d in Py_Main ()
#17 0x00002b3dcdf091c4 in __libc_start_main () from /lib/libc.so.6
#18 0x00000000004139a9 in _start ()


Peace,
Brendon

Hi,

Some more information I've discovered about this bug:

1) A test on a friend's 32-bit PowerPC machine didn't reproduce it. (Maybe a
64-bit issue?)

2) The following equivalent C code does not reproduce it:

#include <GL/glut.h>
#include <stdio.h>

void disFunc() {
    printf("disFunc\n");
    fflush(stdout);
}

void keyFunc(unsigned char c, int a, int b) {
    printf("keyFunc\n");
    fflush(stdout);
}

int main(int argc, char** args) {
    glutInit(&argc, args);
    glutInitDisplayMode(GLUT_RGB);
    glutInitWindowSize(640, 480);
    glutCreateWindow("appname");
    glutDisplayFunc(disFunc);
    glutKeyboardFunc(keyFunc);
    glutMainLoop();
    return 0;
}

That suggests that it's something about the OpenGL wrapper itself.

Peace,
Brendon

Good news. After updating the python2.5 package to 2.5.2-6 I can no longer
reproduce this problem. It seems something between 2.5.2-1 and 2.5.2-6 fixed
whatever was causing this.

Peace,
Brendon

Hi,


closing the report.


best regards,


Torsten

Hi!;

I'm having the same problem reported by this bug but in python-opengl
3.0.0~b3-1 version.

I'm reproducing the SIGSEGV with Brendon's smallest code either on
Python 2.5 and Python 2.4; and having no problem compiling the
equivalent C code attached by Brenton.

On other machines, testing with Debian 32bits and Ubuntu 64bits the bug
isn't manifesting.

My video card is a Intel 82945G/GZ and the driver is i810.

Regards;
Sebastián Santisi

Hi Brendon,

can you still reproduce the crash? With python2.5 2.5.2-11.1, the
program doesn't crash any more for me (tested on both x86 and x86_64).


best,


Torsten

Hi,
I've got the same problem

python2.5 2.5.2-11.1

segmentation fault when using glut initialization
I think it must be opengl wrapper problem. Everything was fine in ubuntu 8-04 but
it's no longer working in 8-10.