Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Memory leak in BindingBase.MarshalStringArrayToPtr #144

nitroxis opened this Issue · 3 comments

4 participants


I'm using GL.GetUniformIndices a lot and noticed that my program was allocating around 2 MB per second and never releasing it. It turned out BindingBase.MarshalStringArrayToPtr was allocating memory which is apparently not released correctly.

Simple code to reproduce this issue:

public static void Main(string[] args)
    int[] index = {0};
    string[] name = {"test"};
    GameWindow window = new GameWindow();
    while (true)
        GL.GetUniformIndices(0, 1, name, index);

I set breakpoints at MarshalStringArrayToPtr and FreeStringArrayPtr, but the latter is never called.


I could successfully reproduce the problem with the provided code.


The call to FreeStringArrayPtr is never emitted by Rewrite. I assumed this was the case the other day when I was redoing the bindings (with a new rewriter that does call FreeStringArrayPtr) and I kept getting access violations when calling FreeStringArrayPtr (this is now fixed, see 22760a4). Given that calling the method pretty much guarantees an AV it must of never been called before or someone would of noticed.

@thefiddler thefiddler added this to the 1.1.4 milestone
@thefiddler thefiddler referenced this issue from a commit
@thefiddler thefiddler [Rewrite] Refactored string prologue/epilogues
We currently have three categories of string parameters: `string`,
`string[]` and `StringBuilder`. (OpenTK 1.2 adds one more: `ref
string`.) Each category needs to be marshaled separately into a native
character array.

This commit implements the following changes:
- string[] epilogues are now correctly emitted, instead of being
- string[] prologues and epilogues now use the same local variable name.
- all epilogues are now generated with a single pass over the function
parameters, instead of requiring a separate pass for each category.
- string prologues and epilogues now allocate local variables based on
the relevant parameter *name* rather than the parameter *type*.

Fixes issue #144.

Thanks for the bug report, fixed via #147

@thefiddler thefiddler closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.