1. Anders Ruud
  2. love
  3. Issues

Issues

Issue #67 resolved

memory leaks in love.graphics.setFont()

the_leg
created an issue

The following code runs out of memory in the latest love (tip):

{{{

!lua

function love.draw() love.graphics.setFont(55) end }}}

I was able to patch the current love to fix the memory leak with the attached patch. The main problem seems to be the Font instance created in wrap_graphics.cpp is retained twice, but only released once, so the Font is never destructed. The same thing was happening with the Glyph class.

There still seems to be some memory related issue in this area even with the patch, as the tip is using ~20Mb more than 0.62. Without the setFont() call, the memory usage by tip and 0.62 is about the same.

Comments (7)

  1. Bart van Strien

    I am not quite sure what the patch is supposed to do, I did fix the described memleak though. (feel free to reopen if you think I failed)

    Also, I wanted to add the demo code above is VERY VERY bad, because, as you should know, it creates a new font every single frame.

  2. the_leg reporter
    • changed status to open

    The demo code still runs out of memory for me. Your code change did solve the Font destructor not being called issue. Thanks for looking into this.

  3. the_leg reporter

    It's still leaking. In modules/font/FontData.cpp, the destructor probably should look like this:

    for (unsigned int i = 0; i < MAX_CHARS; i++) {
      delete data[i];
    }
    
    delete[] data;
    

    With the above change I get a segfault. The segfault occurs when ~Gylph() calls data->release(). If I temporarily comment out that call to data->release() the crash goes away and the memory doesn't leak.

  4. Log in to comment