Memory leak in text.Label

[Remy Blank]

The following program leaks about 300 KB per second on my machine
(Windows XP, Python 2.6.5, pyglet 1.1.4, NVIDIA Quadro FX 360M (but I
can observe the same on an Intel 855GME)):

--8<-------------------------------------------------------------
import pyglet

w = pyglet.window.Window()

while not w.has_exit:
w.dispatch_events()
w.clear()
l = pyglet.text.Label("abc", font_size=w.height,
x=w.width/2, y=w.height/2,
anchor_x="center", anchor_y="center")
l.draw()
w.flip()
pyglet.clock.tick()
--8<-------------------------------------------------------------

I know I shouldn't be creating labels in the loop, but this test case
was extracted from a larger application that runs for several hours, and
creates a number of labels during its execution. Currently, the
application dies after 2 hours from memory exhaustion, when it should
run for 8 hours straight.

I have tried peeking into the implementation of Label, TextLayout,
_GlyphBox and Batch, but I have to admit that I got lost along the way.

I am going to try to run the test with a Python memory analyzer, to try
and find what kind of objects take up memory. In the meantime, can
anyone confirm the issue? Any ideas what could be the cause? Any
workarounds that I could try?

Thanks.
-- Remy

[Bruce Smith]

I might be remembering incorrectly, but maybe this is expected and documented behavior. (It certainly is if you pass the Label constructor an explicit Batch.) I think the Label is supposed to continue to exist (taking up room in vertex lists in a Batch) until explicitly destroyed (with its delete or remove method, I forget which), even though it does not get drawn unless you call the draw method (on it or its batch).

- Bruce Smith

[Remy Blank]

Bruce Smith wrote:
> I think the Label is supposed to continue to exist
> (taking up room in vertex lists in a Batch) until explicitly destroyed
> (with its delete or remove method, I forget which), even though it does
> not get drawn unless you call the draw method (on it or its batch).

There is indeed a delete() method in Label, but adding a call to
l.delete() after l.draw() unfortunately doesn't fix the issue.

I'm currently single-stepping through the test case hoping that I can
understand what's going on under the hood. Any pointers for likely
candidates are welcome.

-- Remy

[Remy Blank]

For future reference, using a Python memory profiler showed that the
memory consumed by Python objects was remaining constant, so the leaked
memory is not accessible from Python and must probably be lost at the C
level.

As a workaround, I ended up caching and re-using Label objects by font,
so that the font is never changed on a once-created Label. This reduced
the leak to a minimum. There still is some leakage, but it is acceptable
for my application, and could be due to a completely different cause.

I'm still interested in trying to fix the leak for good, if anyone has
suggestions what to try.

-- Remy

[Bruce Smith]

If you have time, I suggest filing a bug report with a minimal test case, in case someone has ideas or time later.

- Bruce

[Remy Blank]

Bruce Smith wrote:
> If you have time, I suggest filing a bug report with a minimal test
> case, in case someone has ideas or time later.

Good suggestion, I almost forgot. Here it is:

http://code.google.com/p/pyglet/issues/detail?id=476

-- Remy