Memory Leak

[Just-Feeshy]

I found a memory leak in the Lime backend for C++. I tested using a blank project to determine how much memory gets allocated in 10 minutes. I encountered this memory leak on my framework, which uses a custom-built NDLL. So I can be confident that the memory leak doesn't occur in the ContextMakeCurrent method or the OpenGLBindings class. The memory leak takes up only 70 kb every minute, which isn't much but could add up over time.

I'm using an M1 Macbook and the latest release version of Lime.

Start of the program

10 minutes after the initial start

[flashultra]

Do you have a source code ( project) where the issue exists ? Could you publish it ? What target you test ( Mac OS native, iOS native, android ) ?

[Just-Feeshy]

I'm targeting Mac OS native. I haven't done anything special to modify the project.

package;

import lime.app.Application;

class Main extends Application
{
    public function new()
    {
        super();
    }
}

[Just-Feeshy]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

[barisyild]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

I think the problem is with hxcpp, not Lime.

[Just-Feeshy]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

I think the problem is with hxcpp, not Lime.

That would actually make more sense since I still can't find anything that may cause small chunks of memory to be allocated each couple of minutes.

[barisyild]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

I think the problem is with hxcpp, not Lime.

That would actually make more sense since I still can't find anything that may cause small chunks of memory to be allocated each couple of minutes.

Hxcpp performs garbage collection with the mark and sweep method.

If it cannot find a space to fit the allocated memory at that moment, it creates a new memory block.

The problem may probably be caused by this, the memory is actually empty, there should only be a used area somewhere in the middle of the memory.

[Just-Feeshy]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

I think the problem is with hxcpp, not Lime.

That would actually make more sense since I still can't find anything that may cause small chunks of memory to be allocated each couple of minutes.

Hxcpp performs garbage collection with the mark and sweep method.

If it cannot find a space to fit the allocated memory at that moment, it creates a new memory block.

The problem may probably be caused by this, the memory is actually empty, there should only be a used area somewhere in the middle of the memory.

Is there really any way to fix that from a project codebase standpoint? (Like a regular .hxml Haxe project or Lime project)

[barisyild]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

I think the problem is with hxcpp, not Lime.

That would actually make more sense since I still can't find anything that may cause small chunks of memory to be allocated each couple of minutes.

Hxcpp performs garbage collection with the mark and sweep method.

If it cannot find a space to fit the allocated memory at that moment, it creates a new memory block.

The problem may probably be caused by this, the memory is actually empty, there should only be a used area somewhere in the middle of the memory.

Is there really any way to fix that from a project codebase standpoint? (Like a regular .hxml Haxe project or Lime project)

The only solution is to use the hxcpp_gc_moving define.

However, since this solution is not supported by lime, your application will crash.

[barisyild]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

I think the problem is with hxcpp, not Lime.

That would actually make more sense since I still can't find anything that may cause small chunks of memory to be allocated each couple of minutes.

Hxcpp performs garbage collection with the mark and sweep method.

If it cannot find a space to fit the allocated memory at that moment, it creates a new memory block.

The problem may probably be caused by this, the memory is actually empty, there should only be a used area somewhere in the middle of the memory.

Is there really any way to fix that from a project codebase standpoint? (Like a regular .hxml Haxe project or Lime project)

So there is no solution for hxcpp, can you try hashlink?

[Just-Feeshy]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

I think the problem is with hxcpp, not Lime.

That would actually make more sense since I still can't find anything that may cause small chunks of memory to be allocated each couple of minutes.

Hxcpp performs garbage collection with the mark and sweep method.

If it cannot find a space to fit the allocated memory at that moment, it creates a new memory block.

The problem may probably be caused by this, the memory is actually empty, there should only be a used area somewhere in the middle of the memory.

Is there really any way to fix that from a project codebase standpoint? (Like a regular .hxml Haxe project or Lime project)

So there is no solution for hxcpp, can you try hashlink?

I don't have nor do I know how to setup Hashlink on my mac

[barisyild]

If I had to guess, due to the size of the memory leak, it's probably a raw string (char*) not being freed properly.

I think the problem is with hxcpp, not Lime.

That would actually make more sense since I still can't find anything that may cause small chunks of memory to be allocated each couple of minutes.

Hxcpp performs garbage collection with the mark and sweep method.

If it cannot find a space to fit the allocated memory at that moment, it creates a new memory block.

The problem may probably be caused by this, the memory is actually empty, there should only be a used area somewhere in the middle of the memory.

Is there really any way to fix that from a project codebase standpoint? (Like a regular .hxml Haxe project or Lime project)

So there is no solution for hxcpp, can you try hashlink?

I don't have nor do I know how to setup Hashlink on my mac

If you want to start a new project and do not want to leak memory, I definitely do not recommend openfl targets other than javascript.

Targets other than JavaScript are definitely bad at memory management. If you're going to allocate/deallocate all the time, don't get involved!

[barisyild]

However, if you want to try hashlink, I know that compiling the project as hashlink is enough.

[Just-Feeshy]

However, if you want to try hashlink, I know that compiling the project as hashlink is enough.

Thanks! I appreciate your help a lot! I'll definitely try out hashlink and see how that goes.

[barisyild]

Can I ask something just to be sure? Can you add the following tag in project.xml for the hxcpp target? I believe it will solve any memory leak problem.

<define name="cairo" />

[Just-Feeshy]

Can I ask something just to be sure? Can you add the following tag in project.xml for the hxcpp target? I believe it will solve any memory leak problem.

<define name="cairo" />

How would cairo fix it, you don't mind me asking?