Segmentation fault on amd64 in glutInitDisplayMode()

Can you test with the Intrepid version? This is version 3.0.0~b3.

I've been able to run successfully your example, without segfault, on an amd64:
fabrice@fabrice-desktop:~/temp/PyOpenGL-Demo-3.0.0b6/PyOpenGL-Demo$ python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from OpenGL.GL import *
>>> from OpenGL.GLU import *
>>> from OpenGL.GLUT import *
>>> glutInit([''])
['']
>>> glutInitDisplayMode (GLUT_SINGLE | GLUT_RGB)
>>>

I'm encountering the same crash on Intrepid i386.

[mernisse@wintermute ~/Downloads (2432)]: dpkg -l python-opengl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii python-opengl 3.0.0~b3-1ubun Python bindings to OpenGL

[mernisse@wintermute ~/Downloads (2435)]: python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from OpenGL.GL import *
>>> from OpenGL.GLU import *
>>> from OpenGL.GLUT import *
>>> glutInit([''])
['']
>>> glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB)
Segmentation fault

Hi,
Can you please run python from gdb:
gdb python
run
and then introduce the python commands.
when segfault happen, run backtrace, and post the result here.
Thanks.

>>> glutInitDisplayMode (GLUT_SINGLE | GLUT_RGB)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f487693f6e0 (LWP 2645)]
0x00007f48769080f0 in ?? ()
(gdb) bt
#0 0x00007f48769080f0 in ?? ()
#1 0x00007f4875064aec in ffi_call_unix64 ()
   from /usr/lib/python2.5/lib-dynload/_ctypes.so
#2 0x00007f4875064975 in ffi_call ()
   from /usr/lib/python2.5/lib-dynload/_ctypes.so
#3 0x00007f487505f907 in _CallProc ()
   from /usr/lib/python2.5/lib-dynload/_ctypes.so
#4 0x00007f487505955f in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#5 0x0000000000417e73 in PyObject_Call ()
#6 0x00000000004860ea in PyEval_EvalFrameEx ()
#7 0x000000000048a376 in PyEval_EvalCodeEx ()
#8 0x00000000004d51f8 in ?? ()
#9 0x0000000000417e73 in PyObject_Call ()
#10 0x000000000041e6af in ?? ()
#11 0x000000000041ab7d in PyObject_CallFunctionObjArgs ()
#12 0x00007f487505958b in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#13 0x0000000000417e73 in PyObject_Call ()
#14 0x00000000004860ea in PyEval_EvalFrameEx ()
#15 0x000000000048a376 in PyEval_EvalCodeEx ()
#16 0x000000000048a492 in PyEval_EvalCode ()
#17 0x00000000004ac459 in PyRun_InteractiveOneFlags ()
#18 0x00000000004ac664 in PyRun_InteractiveLoopFlags ()
#19 0x00000000004ac76a in PyRun_AnyFileExFlags ()
---Type <return> to continue, or q <return> to quit---
#20 0x00000000004145ad in Py_Main ()
#21 0x00007f4875b531c4 in __libc_start_main () from /lib/libc.so.6
#22 0x0000000000413b29 in _start ()
(gdb)

fwiw, I only encounter this crash on my MacBook SantaRosa, with the Intel GMA950 graphics card. I tested it running fine on 8.10 with:

nvidia-glx-177 177.80-0ubuntu2
and
nvidia-glx-173 173.14.12-1-0ubuntu3

on a GeForce 7300go and FX5200 respectively.

All systems appear to have Direct Rendering enabled.

I have seen this bug on two i386 machines. Both were recently upgraded from 8.04 to 8.10. One machine has a Radeon card, the other an Intel on-board.

I have found that if I call glutCreateWindow() before calling glutInitDisplayMode() the problem goes away most of the time.

Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from OpenGL.GL import *
>>> from OpenGL.GLU import *
>>> from OpenGL.GLUT import *
>>> glutInit([''])
['']
>>> glutCreateWindow('this is a test')
1
>>> glutInitDisplayMode (GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH)
>>>

Same problem over here.

$ uname -a
Linux poony 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

$ lsb_release -rd
Description: Ubuntu 8.10
Release: 8.10

I've tested it with python-opengl_3.0.0~b6-3 and python-opengl_3.0.0~b3-1ubuntu2.

just in case you need something to look forward to: this bug still persists in Jaunty.
I am using the Radeon driver. This did not occur with fglrx on intrepid.

here is my backtrace:
#0 0xb7c1f196 in glGetError () from /usr/lib/libGL.so.1
#1 0xb7d21057 in ffi_call_SYSV ()
   from /usr/lib/python2.5/lib-dynload/_ctypes.so
#2 0xb7d20e96 in ffi_call () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#3 0xb7d1be24 in _CallProc () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#4 0xb7d14fc9 in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#5 0x0805d897 in PyObject_Call ()
#6 0x080ccd3d in PyEval_EvalFrameEx ()
#7 0x080cfe95 in PyEval_EvalCodeEx ()
#8 0x081174f1 in ?? ()
#9 0x0805d897 in PyObject_Call ()
#10 0x08063aaa in ?? ()
#11 0x08062676 in PyObject_CallFunctionObjArgs ()
#12 0xb7d15003 in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#13 0x0805d897 in PyObject_Call ()
#14 0x080ccd3d in PyEval_EvalFrameEx ()
#15 0x080cfe95 in PyEval_EvalCodeEx ()
#16 0x080d00a7 in PyEval_EvalCode ()
#17 0x080edadf in PyRun_FileExFlags ()
#18 0x080eddaa in PyRun_SimpleFileExFlags ()
#19 0x08059617 in Py_Main ()
#20 0x08058992 in main ()

this goes down to libGL, so seems Mesa is at fault. But luckily the workaround proposed by Robert Gibbs works.

I can confirm that it doesn't work on ubuntu 8.10 but I can also confirm that the problem disappears when the fglrx is switched on.

Confirm that this causing problem on CentOS as well.

>>] uname -a
Linux ... 2.6.18-92.el5 #1 SMP Tue Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

 >>] /sbin/lspci | grep VGA
01:00.0 VGA compatible controller: nVidia Corporation NV41GL [Quadro FX 1400] (rev a2)

 >>] lsb_release -rd
Description: CentOS release 5.2 (Final)
Release: 5.2

Python 2.6 (r26:66714, Nov 21 2008, 10:53:09)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL
>>> OpenGL.__version__
'3.0.0b6'

Backtrace from gdb:

 >>] gdb python
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1".

(gdb) run
Starting program: /.../dogwynn/bin/python
[Thread debugging using libthread_db enabled]
Python 2.6 (r26:66714, Nov 21 2008, 10:53:09)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
[New Thread 47200948283808 (LWP 29788)]
>>> from OpenGL.GLUT import *
[Detaching after fork from child process 29791. (Try `set detach-on-fork off'.)]
[Detaching after fork from child process 29793.]
[Detaching after fork from child process 29795.]
[Detaching after fork from child process 29797.]
[Detaching after fork from child process 29799.]
[Detaching after fork from child process 29801.]
[Detaching after fork from child process 29808.]
[Detaching after fork from child process 29813.]
[Detaching after fork from child process 29815.]
[Detaching after fork from child process 29824.]
>>> glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47200948283808 (LWP 29788)]
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00002aedd7548ce8 in ffi_call_unix64 ()
    at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/libffi/src/x86/unix64.S:75
#2 0x00002aedd7548b34 in ffi_call (cif=0x7fffd6eac6f0,
    fn=0x2aedd8e3daf0 <glGetError>, rvalue=0x7fffd6eac660,
    avalue=0x7fffd6eac650)
    at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/libffi/src/x86/ffi64.c:430
#3 0x00002aedd7543364 in _CallProc (pProc=0x2aedd8e3daf0 <glGetError>,
    argtuple=<value optimized out>, flags=<value optimized out>, argtypes=0x0,
    restype=0x712a740, checker=0x0)
    at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/callproc.c:814
#4 0x00002aedd753b118 in CFuncPtr_call (self=0x71a6120,
    inargs=0x2aedd3c19050, kwds=0x0)
    at /.../dogwynn/sources/Python-2.6/Modules/_ctypes/_ctypes.c:3855
#5 0x0000000000417bbd in PyObject_Call (func=0x71a6120, arg=0x2aedd3c19050,
    kw=0x0) at Objects/abstract.c:2487
#6 0x0000000000490ae6 in PyEval_EvalFrameEx (f=0x729e770,
    throwflag=<value optimized out>) at Python/ceval.c:3890
#7 0x000...

I can report having this problem on my new amd64 Ubuntu Hardy installation. However, I also have a previous Kubuntu Hardy installation on the same machine which does not have the problem.

I assumed in my case that it was a driver problem as glxinfo screwed my display. Having disabled the restricted rivers in Ubuntu, glxinfo and glxgears work fine but I now get this problem with PyOpenGL.

oscar@uwench:~$ python --version
Python 2.5.2
oscar@uwench:~$ uname -a
Linux uwench 2.6.24-23-generic #1 SMP Thu Nov 27 18:13:46 UTC 2008 x86_64 GNU/Linux
oscar@uwench:~$ python
>>> OpenGL.__version__
'3.0.0b1'

The same on i686 Ubuntu 8.10/Python2.6/PyOpenGL 3.0.0c1

but the cause seems to be another

:~$ python --version
Python 2.6.2

:~$ uname -a
Linux <machine> 2.6.27-11-generic #1 SMP Wed Apr 1 20:57:48 UTC 2009 i686 GNU/Linux

:~$ python
Python 2.6.2 (r262:71600, Apr 16 2009, 10:57:41)
[GCC 4.3.2] on linux2
>>> import OpenGL
>>> OpenGL.__version__
'3.0.0c1'

:~$ gdb python
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: /usr/local/bin/python
[Thread debugging using libthread_db enabled]
Python 2.6.2 (r262:71600, Apr 16 2009, 10:57:41)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
[New Thread 0xb7e8c8c0 (LWP 20735)]
>>> from OpenGL import GLUT
>>> GLUT.glutInitDisplayMode(GLUT.GLUT_RGBA | GLUT.GLUT_DOUBLE)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7e8c8c0 (LWP 20735)]
0xb7c26156 in glGetError () from /usr/lib/libGL.so.1
(gdb) bt
#0 0xb7c26156 in glGetError () from /usr/lib/libGL.so.1
#1 0xb7cdbf67 in ffi_call_SYSV ()
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/libffi/src/x86/sysv.S:61
#2 0xb7cdbda6 in ffi_call (cif=0xbfc603a8, fn=0xb7c26150 <glGetError>,
    rvalue=0x0, avalue=0xbfc60420)
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/libffi/src/x86/ffi.c:213
#3 0xb7cd64aa in _CallProc (pProc=0xb7c26150 <glGetError>,
    argtuple=0xb7e4c02c, flags=<value optimized out>, argtypes=0x0,
    restype=0x93402f4, checker=0x0)
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/callproc.c:815
#4 0xb7ccdda9 in CFuncPtr_call (self=0xb7c617e4, inargs=0xb7e4c02c, kwds=0x0)
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/_ctypes.c:3857
#5 0x0805f6ca in PyObject_Call (func=0xb7c617e4, arg=0xb7e4c02c, kw=0x0)
    at Objects/abstract.c:2492
#6 0x080dace2 in PyEval_EvalFrameEx (f=0x93ae2ac, throwflag=0)
    at Python/ceval.c:3917
#7 0x080dddb8 in PyEval_EvalCodeEx (co=0xb7c7ee78, globals=0xb7c8802c,
    locals=0x0, args=0xb7e3d970, argcount=4, kws=0x0, kwcount=0,
    defs=0xb7c83cf8, defcount=2, closure=0x0) at Python/ceval.c:2968
---Type <return> to continue, or q <return> to quit---
#8 0x0813206f in function_call (func=0xb7c7f844, arg=0xb7e3d964, kw=0x0)
    at Objects/funcobject.c:524
#9 0x0805f6ca in PyObject_Call (func=0xb7c7f844, arg=0xb7e3d964, kw=0x0)
    at Objects/abstract.c:2492
#10 0x080665ca in instancemethod_call (func=0xb7c7f844, arg=0xb7e3d964, kw=0x0)
    at Objects/classobject.c:2579
#11 0x080640d1 in PyObject_CallFunctionObjArgs (callable=0xb7d21eb4)
    at Objects/abstract.c:2492
#12 0xb7ccdde3 in CFuncPtr_call (self=0xb78bd984, inargs=0xb7e7ad0c, kwds=0x0)
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/_ctypes.c:3873
#13 0x0805f6ca in PyObject_Call (func=0xb78bd984, arg=0xb7e7ad0c, kw=0x0)
...

sudo apt-get install xorg-driver-fglrx

this installation is fixed the problem. So, if it is possible to make a message about the drivers requirement while installing the module, it will be perfect

I've tried this with an internal Intel video card: it showed the window, but it there were some artifacts and the window was unable to do anything (close/maximize/resize) and showed Segmentation Fault when window is closed with Alt+F4. I've clearly removed all ati fglrx drivers, made a reboot. and it fails with Segmentation Fault again:

So, if I'll follow the logic with ATI drivers, I need an Intel drivers, but they are pre-installed with Ubuntu 8.10

...
>>> from OpenGL import GLUT
>>> GLUT.glutInitDisplayMode(GLUT.GLUT_RGBA | GLUT.GLUT_DOUBLE)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d588c0 (LWP 6055)]
0xb7af2156 in glGetError () from /usr/lib/libGL.so.1
(gdb) bt
#0 0xb7af2156 in glGetError () from /usr/lib/libGL.so.1
#1 0xb7ba7f67 in ffi_call_SYSV ()
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/libffi/src/x86/sysv.S:61
#2 0xb7ba7da6 in ffi_call (cif=0xbf929018, fn=0xb7af2150 <glGetError>,
    rvalue=0x0, avalue=0xbf929090)
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/libffi/src/x86/ffi.c:213
#3 0xb7ba24aa in _CallProc (pProc=0xb7af2150 <glGetError>,
    argtuple=0xb7d1802c, flags=<value optimized out>, argtypes=0x0,
    restype=0xa19d444, checker=0x0)
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/callproc.c:815
#4 0xb7b99da9 in CFuncPtr_call (self=0xb7b287e4, inargs=0xb7d1802c, kwds=0x0)
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/_ctypes.c:3857
#5 0x0805f6ca in PyObject_Call (func=0xb7b287e4, arg=0xb7d1802c, kw=0x0)
    at Objects/abstract.c:2492
#6 0x080dace2 in PyEval_EvalFrameEx (f=0xa20af34, throwflag=0)
    at Python/ceval.c:3917
#7 0x080dddb8 in PyEval_EvalCodeEx (co=0xb7b45e78, globals=0xb7b4f02c,
    locals=0x0, args=0xb7d09948, argcount=4, kws=0x0, kwcount=0,
    defs=0xb7b4acf8, defcount=2, closure=0x0) at Python/ceval.c:2968
---Type <return> to continue, or q <return> to quit---
#8 0x0813206f in function_call (func=0xb7b46844, arg=0xb7d0993c, kw=0x0)
    at Objects/funcobject.c:524
#9 0x0805f6ca in PyObject_Call (func=0xb7b46844, arg=0xb7d0993c, kw=0x0)
    at Objects/abstract.c:2492
#10 0x080665ca in instancemethod_call (func=0xb7b46844, arg=0xb7d0993c, kw=0x0)
    at Objects/classobject.c:2579
#11 0x080640d1 in PyObject_CallFunctionObjArgs (callable=0xb7bede8c)
    at Objects/abstract.c:2492
#12 0xb7b99de3 in CFuncPtr_call (self=0xb7789984, inargs=0xb7d46d0c, kwds=0x0)
    at /home/shamansir/Software/Packages/Python-2.6.2/Modules/_ctypes/_ctypes.c:3873
#13 0x0805f6ca in PyObject_Call (func=0xb7789984, arg=0xb7d46d0c, kw=0x0)
    at Objects/abstract.c:2492
#14 0x080dace2 in PyEval_EvalFrameEx (f=0xa187034, throwflag=0)
    at Python/ceval.c:3917
#15 0x080dddb8 in PyEval_EvalCodeEx (co=0xb7ce4e30, globals=0xb7d3b0b4,
    locals=0xb7d3b0b4, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2968
#16 0x080ddf17 in PyEval_EvalCode (co=0xb7ce4e30, globals=0xb7d3b0b4,
    locals=0xb7d3b0b4) at Python/ceval.c:522
#17 0x080fb6b5 in PyRun_InteractiveOneFlags (fp=0xb7eb3420,
    filename=0x81490df "<stdin>", flags=0xbf929db8) at Pyth...

Yes, making the code look like this, completely resolves this segmentation fault problem:

        GLUT.glutInit(sys.argv)
        GLUT.glutCreateWindow('foobar') # required to be a line before glutInitDisplay
        GLUT.glutInitDisplayMode(GLUT.GLUT_RGBA | GLUT.GLUT_DOUBLE)

(thanks to: http://henryestaescrevendo.blogspot.com/2009/03/pyopengl-segmentation-fault.html and a ~gibbsrc comment above)

Sorry for the big number of comments

Can you please test with 3.0.0 final in my PPA https://launchpad.net/~robert-ancell/+archive/ppa. (bug 351284)

I just tested the package provided by Robert. It still gives segfault. It gives the same backtrace as before in https://bugs.launchpad.net/debian/+source/pyopengl/+bug/289925/comments/12 .

I'm using Jaunty i386 with Mobility Radeon 9700 (64MB) here. Note that it worked just fine in Hardy using fglrx driver.

Same here. Still seg faults. i386 w/intel graphics.

2009/5/7 Juho Vepsäläinen <email address hidden>

> I just tested the package provided by Robert. It still gives segfault.
> It gives the same backtrace as before in
> https://bugs.launchpad.net/debian/+source/pyopengl/+bug/289925/comments/12
> .
>
> I'm using Jaunty i386 with Mobility Radeon 9700 (64MB) here. Note that
> it worked just fine in Hardy using fglrx driver.
>
> --
> Segmentation fault on amd64 in glutInitDisplayMode()
> https://bugs.launchpad.net/bugs/289925
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Thanks for the testing. I've found the upstream issue and linked it to this one:
http://sourceforge.net/support/tracker.php?aid=1737282

It seems like we have something like the following:

 * race condition where native drivers are fast enough not to crash (i.e. they are filling out an internal structure before the call to glutInit)
 * use of a GL operation by FreeGLUT that requires a GL context under MESA, but does not under the proprietary drivers
 * use of a MESA operation that is buggy in software but correct in the common hardware implementations

I'll try again to reproduce the effect on my Ubuntu machine.

Okay, on my Jaunty AMD64 I cannot replicate the problem even when I switch to MESA software renderer (it doesn't occur with fglrx driver either). However, looking through the tracebacks posted, it seems pretty obvious that some configurations are failing when a call to glGetError happens before the GL has a context. There's nothing in the docs which says that should ever cause a failure (let alone a segfault), so it seems we're looking at a broken implementation issue.

We could work around it by disabling GLUT error checking entirely, but that seems a bit of a nuclear option, as it would change the API. Instead I'm thinking we'll disable error checking *just* for the GLUT functions commonly called before the GLUT context is created. I've checked in changes to bzr head to implement this. Please do the following and report whether the bug is fixed for you:

    bzr branch lp:pyopengl
    # add pyopengl/OpenGL to your PYTHONPATH

then run the test script.

Mike C. Fletcher wrote:
>We could work around it by disabling GLUT error checking entirely, but that seems a bit of a nuclear option, as it would >change the API. Instead I'm thinking we'll disable error checking *just* for the GLUT functions commonly called before >the GLUT context is created. I've checked in changes to bzr head to implement this. Please do the following and report >whether the bug is fixed for you:
>
> bzr branch lp:pyopengl
> # add pyopengl/OpenGL to your PYTHONPATH
>
>then run the test script.

I just tested this and it still results in the same backtrace as before (I added pyopengl/OpenGL to Python path using "export PYTHONPATH=<path to branch>/pyopengl/OpenGL" on terminal.).

Interestingly pyglet (http://www.pyglet.org/) gives the exact same backtrace! I tested this importing (import hello_world) the Hello World! example (http://www.pyglet.org/doc/programming_guide/hello_world.py) from Pyglet documentation into my gdb Python session.

Pyglet is ok for my configuration (no segmentation or any other (except sound, when it used) failures in hello_world or any other example from source package), but the PyOpenGL lines, described above, still fail.

Ubuntu 9.04
Python 2.6.2
pyglet 1.1.3
Intel Graphics Video Card

Let me try to recap:

1) Issue does not seem to be related with amd64 (32 bit jaunty manifests it too).
2) Issue does not seem to be related with OpenGL library per se, since examples in C/C++ run with no problems, although this could be due to the fact that compiled examples do not incur in the same "race conditions".
3) It does not have to do with glut under pyopengl (pyglet / pygame manifest it too), although it DOES seem to be related with pyopengl 3.
4) It does not have to do with particular graphics drivers, since it manifests with ati, intel drivers.
5) It's not clear whether it's a Jaunty problem since there are reports for similar trouble in CentOS.
6) It does not seem to be related with Python 2.6, since there are reports for similar trouble in Python 2.5.
7) It's not clear whether this is related to x 2.6 (any clues?)

I disagree, however, that this has "low" importance, since it effectively breaks pyopengl on Jaunty...

I 100% Agree with this. pyopengl for some of the most popular distros is completely broken. Thats a showstopper in my book.

I'm fine with a higher priority, but as of yet I have no reproducibility. As a check, can someone do:

import OpenGL
OpenGL.ERROR_CHECKING = False

in one of their test scripts? That might at least tell me whether it's really the glGetError call causing the problem or whether that just happens to show up in the error reports. *Pyglet* showing the problem is just *weird*, there's no common code between pyglet and PyOpenGL other than ctypes and Python. If we have a problem there we're looking at a methodology failure or a problem with ctypes/Python.

By disabling error checking as above, I do not get a seg fault error anymore, although I do see the cryptic message

get fences failed: -1
param: 6, val: 0

About pyglet: it seems to work on my machine (MSI Wind, Pyopengl 3.0b5, Jaunty). I mentioned it above because of an earlier post claiming it "gave the same back trace"...

I can confirm this bug still exists with the latest version of PyOpenGL from their bzr site:

>>> import OpenGL
>>> print OpenGL.__version__
3.0.0b6

>>>
>>> from OpenGL import GLUT
>>> GLUT.glutInitDisplayMode(GLUT.GLUT_RGBA | GLUT.GLUT_DOUBLE)
Segmentation fault

with the following backtrace

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7ebe6c0 (LWP 7060)]
0xb7c9c196 in glGetError () from /usr/lib/libGL.so.1
(gdb) backtrace
#0 0xb7c9c196 in glGetError () from /usr/lib/libGL.so.1
#1 0xb7d06107 in ffi_call_SYSV ()
   from /usr/lib/python2.6/lib-dynload/_ctypes.so
#2 0xb7d05f46 in ffi_call () from /usr/lib/python2.6/lib-dynload/_ctypes.so
#3 0xb7d0064a in _CallProc () from /usr/lib/python2.6/lib-dynload/_ctypes.so
#4 0xb7cf7f49 in ?? () from /usr/lib/python2.6/lib-dynload/_ctypes.so
#5 0x0806111a in PyObject_Call ()
#6 0x080dcfea in PyEval_EvalFrameEx ()
#7 0x080e00b8 in PyEval_EvalCodeEx ()
#8 0x081687df in ?? ()
#9 0x0806111a in PyObject_Call ()
#10 0x0806801a in ?? ()
#11 0x08065b21 in PyObject_CallFunctionObjArgs ()
#12 0xb7cf7f83 in ?? () from /usr/lib/python2.6/lib-dynload/_ctypes.so
#13 0x0806111a in PyObject_Call ()
#14 0x080dcfea in PyEval_EvalFrameEx ()
#15 0x080e00b8 in PyEval_EvalCodeEx ()
#16 0x080e0217 in PyEval_EvalCode ()
#17 0x080fdc45 in PyRun_InteractiveOneFlags ()
#18 0x080fded8 in PyRun_InteractiveLoopFlags ()
#19 0x080fe716 in PyRun_AnyFileExFlags ()
#20 0x0805c882 in Py_Main ()
#21 0x0805b972 in main ()

After I disable error checking it works fine.

For me, to fix this problem just replace libgl1-mesa-glx by libgl1-mesa-swx11 (through synaptic)
Hope this help!

#15 Thanks! it works !

Exact same situation as #15 here on my EeePC 1001P. Ubuntu 9.10, OpenGL.__version__ == '3.0.0', Python 2.6.4. I'm not currently using Glut for my own project, but all the python examples that use it are now broken, including the GLContext tests.

This bug was fixed for the 3.0.1 release by disabling GL error-checking on GLUT functions. This is another case of (some) newer GL implementations being extremely anal about calls to GL entry points before there is a GL context. Basically the glGetError() calls were seg-faulting because GLUT didn't have a context set up yet.

glutCreateWindow segfaulted here both with the simplest possible PyOpenGL example and also with the simplest possible example in C. This was with an Intel 855GM with a 16-bit display on Debian Squeeze. Changing the display to 24-bit made the segfault go away.