Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago I was seeing this on ubuntu. I have since upgraded to Ubuntu jaunty and the
issue is
gone (replaced with the one described at
http://groups.google.com/group/pyglet-users/msg/738df41a0d0431a0).Original comment by joel.s...@gmail.com on 29 Jan 2009 at 1:20
GoogleCodeExporter
commented
9 years ago I'm seeing the same problem in Fedora 10 (Python 2.5.2, glibc-2.9-3.i686). First
noticed the problem with a program I wrote and which was working previously (in
Fedora 9 at least). Then found out the Hello World sample triggers it, too. I
reduced
it to:
{{{
$ python -c 'import pyglet;window =
pyglet.window.Window();label=pyglet.text.Label("Hello")'
*** glibc detected *** python: corrupted double-linked list: 0x0a27afc8 ***
}}}
Maybe pyglet is returning objects with incorrect references and some change in
glibc
or Python is making it visible now?
Original comment by risto.ka...@gmail.com on 4 Apr 2009 at 11:00
GoogleCodeExporter
commented
9 years ago Maybe so. I don't really understand what the error is saying, other than it is
something to do with the underlying c code, which is well outside my field of
experience, so I'm not really qualified to say anything other than that sounds
feasible. I was only just starting to play around with it, and didn't get very
far.
Not a great first impression.Original comment by dominicb...@googlemail.com on 4 Apr 2009 at 11:50
GoogleCodeExporter
commented
9 years ago I started looking closer into pyglet implementation and remembered that I had
forgotten it's pure Python, the interfacing to GL is done with ctypes. So it's
probably not a reference count error, rather it's a problem in the pyglet code
that
manipulates ctypes objects.
Running the hello_world.py with a tracer surprisingly ends up dumping a stack
trace
in addition to the corruption message. I guess the tracer alters the memory
layout or
something else that triggers the corruption in a different place:
$ python -m trace -l hello_world.py
Mesa 7.3-devel implementation error: referencing deleted buffer object
Please report at bugzilla.freedesktop.org
Traceback (most recent call last):
File "/usr/lib/python2.5/runpy.py", line 95, in run_module
filename, loader, alter_sys)
File "/usr/lib/python2.5/runpy.py", line 52, in _run_module_code
mod_name, mod_fname, mod_loader)
File "/usr/lib/python2.5/runpy.py", line 32, in _run_code
exec code in run_globals
File "/usr/lib/python2.5/trace.py", line 794, in <module>
main()
File "/usr/lib/python2.5/trace.py", line 782, in main
t.run('execfile(%r)' % (progname,))
File "/usr/lib/python2.5/trace.py", line 489, in run
exec cmd in dict, dict
File "<string>", line 1, in <module>
File "hello_world.py", line 56, in <module>
pyglet.app.run()
File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 264, in run
File "build/bdist.linux-i686/egg/pyglet/app/xlib.py", line 94, in run
File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 193, in idle
File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 1217, in dispatch_event
File "build/bdist.linux-i686/egg/pyglet/event.py", line 340, in dispatch_event
File "/home/black/Download/hello_world.py", line 54, in on_draw
label.draw()
File "build/bdist.linux-i686/egg/pyglet/text/layout.py", line 837, in draw
File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 538, in draw
File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 470, in <lambda>
File "build/bdist.linux-i686/egg/pyglet/graphics/vertexdomain.py", line 270, in draw
File "build/bdist.linux-i686/egg/pyglet/graphics/vertexbuffer.py", line 398, in bind
File "build/bdist.linux-i686/egg/pyglet/gl/lib.py", line 105, in errcheck
pyglet.gl.lib.GLException: invalid enumerant
*** glibc detected *** python: double free or corruption (!prev): 0x09112370 ***
Running hello_world.py with a privately built egg fails with the same glibc
message,
and strangely enough running hello_world.py with trace module results in the
stack
trace, but NOT the glibc corruption message!
Original comment by risto.ka...@gmail.com on 5 Apr 2009 at 11:14
GoogleCodeExporter
commented
9 years ago I noticed that I can trigger the problem with the test case RETAINED.test_v3f
so I
ran it through pdb. I think the problem happened in the VBO code: the test has
a 42
element array. The VBO code allocates a buffer with initial capacity of 16
elements
and then has to expand that to 64 elements to fit the 42 elements from the test
case.
The code allocates a new buffer, copies the contents of the old one and then
_safe
alloc() calls glBindBuffer and glBufferData. This is where I see either a GL
exception or glibc memory corruption error.
At this point I also noticed pyglet's extensive debugging options and could
come with
the same conclusion by just running:
PYGLET_DEBUG_GL_TRACE=True PYGLET_DEBUG_TRACE=True PYGLET_DEBUG_TRACE_DEPTH=10
PYGLET_DEBUG_TRACE_ARGS=True python pyglet/pyglet-1.1.3/tests/test.py
I tried changing the _initial_count from 16 to 128 in order to avoid
reallocation of
the buffer, but then I started getting "Segmentation fault". So the error is
not in
the reallocation part but in the VBO code in general.
I hope someone can take it from here and look all the ctypes memory allocation
and
pointer stuff a bit more closely.
At the same time as looking into the debugging options I found the
graphics_vbo=True
default setting. Since I had seen problems in the VBO code, I tried running the
tests
with PYGLET_GRAPHICS_VBO=False. The tests run fine!
I tried the same thing with my app and I could run it successfully too!
PYGLET_GRAPHICS_VBO=False python my-pyglet-app.py
Having found this workaround I'm a bit less motivated to determine the Pyglet
problem
now when I finally can work on my app...
Original comment by risto.ka...@gmail.com on 12 Apr 2009 at 11:51
GoogleCodeExporter
commented
9 years ago Original comment by m.e.w.ol...@gmail.com on 14 Aug 2009 at 12:22
GoogleCodeExporter
commented
9 years ago Original comment by benjamin...@gmail.com on 20 Aug 2009 at 1:57
GoogleCodeExporter
commented
9 years ago Is the error still there in 1.1.4 and/or mercurial trunk?Original comment by Adam.JT...@gmail.com on 19 Sep 2011 at 4:32
GoogleCodeExporter
commented
9 years ago I don't have this problem and having not had a response from any of the
original reporters for over a year I'm marking it invalid.Original comment by Adam.JT...@gmail.com on 11 Dec 2012 at 10:24
Original issue reported on code.google.com by
dominicb...@googlemail.comon 26 Jan 2009 at 10:36