possible memory leaks in the OpenGL plugin

Bug #1227449 reported by Daniel Koukola
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Compiz
Fix Released
High
Stephen M. Webb
0.9.11
Triaged
High
Unassigned
Trusty
New
High
Unassigned
compiz (Ubuntu)
Fix Released
High
Unassigned
Nominated for Trusty by Stephen M. Webb
Nominated for Utopic by Stephen M. Webb

Bug Description

It looks like that objects allocated inside GLWindow::addShaders and GLVertexBuffer::addUniform methods are never deleted.

I'm using a plugin (compiz-cms) that uses both those methods and it leaks memory very fast:

==21530== 24,821,632 (10,638,048 direct, 14,183,584 indirect) bytes in 443,252 blocks are definitely lost in loss record 1,143 of 1,145
==21530== at 0x4A068F3: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21530== by 0x6536B2C: GLVertexBuffer::addUniform(char const*, int) (in /usr/lib64/compiz/libopengl.so)
==21530== by 0xC351FFB: CmsWindow::glDrawTexture(GLTexture*, GLMatrix const&, GLWindowPaintAttrib const&, unsigned int) (cms.cpp:530)
==21530== by 0x652F030: GLWindow::glDrawTexture(GLTexture*, GLMatrix const&, GLWindowPaintAttrib const&, unsigned int) (in /usr/lib64/compiz/libopengl.so)

==21530== 128,089,075 (10,638,072 direct, 117,451,003 indirect) bytes in 443,253 blocks are definitely lost in loss record 1,145 of 1,145
==21530== at 0x4A068F3: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21530== by 0x653872D: GLWindow::addShaders(std::string, std::string, std::string) (in /usr/lib64/compiz/libopengl.so)
==21530== by 0xC351F8E: CmsWindow::glDrawTexture(GLTexture*, GLMatrix const&, GLWindowPaintAttrib const&, unsigned int) (cms.cpp:529)
==21530== by 0x652F030: GLWindow::glDrawTexture(GLTexture*, GLMatrix const&, GLWindowPaintAttrib const&, unsigned int) (in /usr/lib64/compiz/libopengl.so)

Tags: patch

Related branches

Revision history for this message
MC Return (mc-return) wrote :

Look like new without delete case bugs.

Thanks 4 the detailed report. +1

Do you have a patch fixing the leaks also ?

Changed in compiz:
milestone: none → 0.9.11.0
importance: Undecided → Critical
status: New → Triaged
importance: Critical → High
Revision history for this message
Daniel Koukola (dan-atrey) wrote :

I'm afraid I don't understand that code well enough to fix it correctly. It seems that all uniforms could be deleted before deleting or clearing the container that contains them. But for shaders that doesn't work as some of them come from the shader cache (auto program?) and those shouldn't be deleted.

Revision history for this message
Daniel Koukola (dan-atrey) wrote :

Attached a quick fix. But maybe it would be better to use boost::shared_ptr?

Revision history for this message
MC Return (mc-return) wrote :

Daniel, thanx a lot 4 your patch. Looks good to me at first glance.

You do not need the brackets, if there is just one statement in the if condition/for loop though, but that is a minor coding style issue only...
Not sure about boost::shared_ptr and I am also not a shader expert, but I would say: "If your patch fixes the leaks without crashing the shader, all should be good." ;)
I will test your patch and report back, although I am not sure, if I am able to reproduce the leaks as just the "Negative" plugin seems to use GLWindow::addShaders.

If you have an improved version in the meantime, do not hesitate to post it here.

Revision history for this message
Stephen M. Webb (bregma) wrote :

The attached patch no longer applies but the leaks are still evident on inspection of the code.

Changed in compiz:
milestone: 0.9.11.0 → 0.9.12.0
Stephen M. Webb (bregma)
Changed in compiz (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in compiz:
status: Triaged → In Progress
assignee: nobody → Stephen M. Webb (bregma)
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "compiz-fix-opengl-leak.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.9.12+15.04.20141031-0ubuntu1

---------------
compiz (1:0.9.12+15.04.20141031-0ubuntu1) vivid; urgency=low

  [ Stephen M. Webb ]
  * filter debian/ from upstream dist tarball (LP: #1075995)
  * removed distro-patch for #873384 because it's now upstream (LP:
    #873384)
  * removed inappropriate executable permissions from some source and
    data files (LP: #1086165)
  * window_decorator: renamed a local to unhide a parameter (LP:
    #957600)
  * opengl plugin: free shaders and uniforms (LP: #1227449)
  * debian/compizconfig: renamed from debian/config to avoid debconf
    clashes (LP: #1156294)
  * animation plugin: initialize mPrevAnimSelectionRow (LP: #1101630)

  [ Klaus Knopper ]
  * Forces non-opaque pointer in the ezoom plugin. (LP: #1362005)

  [ Henry Hu ]
  * place plugin: correct min and default placement modes in
    configuration

  [ Matija Skala ]
  * remove 'extern "C"' hack (LP: #1286562)

  [ Dariusz Gadomski ]
  * CompScreen: Save focused window id before changing viewport.
 -- Ubuntu daily release <email address hidden> Fri, 31 Oct 2014 17:03:50 +0000

Changed in compiz (Ubuntu):
status: Triaged → Fix Released
Stephen M. Webb (bregma)
Changed in compiz:
status: In Progress → Fix Committed
Stephen M. Webb (bregma)
Changed in compiz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.