Memory leak in Hazel? about hazel HOT 30 CLOSED

I'm having the same problem!! Memory leaks just by moving the demo window or moving it outside of the application + it drops a lot of FPS & lags when moving the demo window as you can see.. 16 FPS; That's definitely a bug either in Hazel or ImGui docking branch. p.s I'm using the latest commit.

from hazel.

That's because if we don't call it, the ImGui layer's (ImGuiLayer.cpp) OnDetach won't get called (which frees the memory allocated by ImGui), hence, the memory is leaked.

Edit: the layer is also created and pushed as an overlay in the Application's Constructor

from hazel.

Yap, ImGui is indeed an issue, I'll add it to the list (I only looked at examplelayer)

from hazel.

What exactly are you experiencing? Have you tried running the program in debug mode? Did you find something interesting we might wanna take a look at? In all Honesty I haven't had any sort of problem so far :(

from hazel.

Sandbox.exe has used over 7GB of my RAM when I've left the demo window outside of the viewport for some minutes. I confirm it's a bug.

from hazel.

This might be fixed in #49

from hazel.

Can anyone who had this problem before confirm if it has been fixed or not? @CleverSource or @badryasuo or anyone else.

from hazel.

I'd like to note that #49 introduced a missing semicolon. I've already created new PR #72 which fixes that and is ready to be merged.

For now, you can manually add a semicolon in LayerStack.cpp at the end of the line 34.

from hazel.

@Gaztin I still experience a few memory issues but I updated ImGui docking branch and it seems to have gotten better, it still has a massive memory spike but it's much more subtle than before. It possibly was coming from docking, maybe have Cherno merge the current ImGui docking branch with his personal ImGui fork?

from hazel.

The ImGui fork has not been updated since February. Hopefully we can update it soon to see if it solves the current memory problems.

from hazel.

Also, there is still a known leak when we close the application as we don't call glfwTerminate anywhere.

from hazel.

Also, there is still a known leak when we close the application as we don't call glfwTerminate anywhere.

Hazel/Hazel/src/Platform/Windows/WindowsWindow.cpp

Lines 42 to 49 in 982dcdf

	if (!s_GLFWInitialized)
	{
	// TODO: glfwTerminate on system shutdown
	int success = glfwInit();
	HZ_CORE_ASSERT(success, "Could not intialize GLFW!");
	glfwSetErrorCallback(GLFWErrorCallback);
	s_GLFWInitialized = true;
	}

The problem is that the @TheCherno wants support for multiple windows, but GLFW initialization should happen at once, so I think that the GLFW initialization should be moved into its own class.
Why we should do this is because any GLFW returned objects are allocated internally and can be freed when we call glfwTerminate(); Here's a link to the documentation

from hazel.

The problem is that the @TheCherno wants support for multiple windows, but GLFW initialization should happen at once, so I think that the GLFW initialization should be moved into its own class.
Why we should do this is because any GLFW returned objects are allocated internally and can be freed when we call glfwTerminate(); Here's a link to the documentation

An easy solution to keep GLFW inside WindowsWindow, keep a static uint_8 s_GLFWWindowCount to track the amount (max 255) of windows that are open.

• In the constructor
  • If s_GLFWWindowCount equals 0, no windows are already open, so we need to initialize GLFW
  • Increment the counter
• In the deconstructor
  • Decrement the counter
  • If s_GLFWWindowCount equals 0, we just closed the last window, so we need to terminate GLFW

This results in the same amount of memory used (that byte for counter or for bool, and no extra classes, this stays contained in WindowsWindow)

Thoughts?

from hazel.

My solution would be simple and elegant. Managing like a ref counting can get complicated.
In EntryPoint.h

...
int main(int argc, char** argv)
{
    Hazel::System system;
    Hazel::Log::Init();
    auto app = Hazel::CreateApplication();
    app->Run():
}
...

from hazel.

In EntryPoint.h

...
int main(int argc, char** argv)
{
    Hazel::System system;
    Hazel::Log::Init();
    auto app = Hazel::CreateApplication();
    app->Run():
}
...

That was my idea before you commented on the linux PR; where I assumed you would want a single entrypoint...

On the other had, depending on the distributions, we might want/not want to have GLFW used; where containing it inside the WindowsWindow (where we are actualy using it), could help to keep GLFW contained to where it is used in the code base...

Having a System around could make our lives alot easier when defining stuff like what renderer we use.. There we could setup all the precompiler stuff that will contain distribution specific stuff, for example defining what renderer we use:

from hazel.

Hi, I wrote another memory leak issue I found on issue #96 and I've been told to share here the problem so everything is together. You can read the issue for full info and the full log of memory leaks, but i'm doing a little sum up.

Important: I've checked this issue on both my repo and last repo of Hazel, so is not just a problem of mine.

I was wandering if there was any memory leaks during the writing of the code (just in case I missed something or wrote something wrong) so I looked for a library to check memory leaks on Windows and the web page of Visual Studio gave this code (marked with <-):

#ifdef CGE_WINDOWS
extern CGE::Game* CGE::BuildGame();

#define _CRTDBG_MAP_ALLOC      <-
#include <stdlib.h>                        <-
#include <crtdbg.h>                      <-

int main(int argc, char** argv) {
	CGE::Logger::initLogger();

	auto _game = CGE::BuildGame();
	_game->run();
	delete _game;

	_CrtDumpMemoryLeaks();      <-
}
 #else
#error Only windows supported yet
#endif

As I wrote on top, the full log is in the issue #96 (I can post it here if needed) and there's a lot of memory leaks. I figured out that they appear once on the premake we start using
buildoptions "/MDd" / buildoptions "/MD"

what we change to

runtime "Debug" / runtime "Release"
and
staticruntime "Off"

The only pointers we have to delete are the Layers from the LayerStack and we are deleting them, so it might be some GLFW problem where we aren't calling a specific function that needs to be called (?)

I don't really know, so any suggestion is welcomed. As I said, the output of the code provided by Visual Studio is here #96 and there are a lot of memory leaks.

from hazel.

As @bovacu discussed in #96, it does still happen on the most recent builds of Hazel.
All relevant information is posted here, closing #96 as duplicate, you can still view the issue for the memory dump itself.

from hazel.

Unfortunately none of this possible fixes worked for me. I was having a huge memory leak in moving my imGui window out from my Sandbox window and then putting some another window on focus (Like having a imGui window in a monitor and VS in another). And just flicking the window inside my Sandbox window also make the leak occurs.

The fact is: After i try this solution, i started to have this memory leak only just for putting the imGui window outside Sandbox's window, not needing to have another window in focus anymore, that is, the leak got worse.

But thank you for trying, and to be honest, i kinda prefer to call OnAttach() from the LayerStack instead calling it from the Application.

from hazel.

He was not proposing a solution; this issue is to uncover a memory leak in Hazel. Can you clarify what you mean by:

After i try this solution

from hazel.

He was not proposing a solution; this issue is to uncover a memory leak in Hazel. Can you clarify what you mean by:

Oh, ok. I thought the problem was already uncovered, so, the part that i can add here is the part before i tried this method (which have relation, in my case, with the focuses of the windows)

from hazel.

On the other had, depending on the distributions, we might want/not want to have GLFW used; where containing it inside the WindowsWindow (where we are actualy using it), could help to keep GLFW contained to where it is used in the code base...

On my other game engine(just for fun) written in Java used interface System and then create GLFWSystem then add it to the list in SystemManager or something like that. That way we can customize what code will be initialized. in this example, glfw or glew(if somebody likes to use that).

from hazel.

On the other had, depending on the distributions, we might want/not want to have GLFW used; where containing it inside the WindowsWindow (where we are actualy using it), could help to keep GLFW contained to where it is used in the code base...

On my other game engine(just for fun) written in Java used interface System and then create GLFWSystem then add it to the list in SystemManager or something like that. That way we can customize what code will be initialized. in this example, glfw or glew(if somebody likes to use that).

That is the path cherno will take as far as I know. Even go as far as conditional includes... This should be a co-op:

1. Core.h should decide what parts of the system will be used (defined with macros)
   • Conditionaly include required files, so unused files are not compiled
   • Determine what systems will be used
2. Systems class as runtime access
   • Init/Run/Shutdown routines
   • static members that characterize the system

from hazel.

We should make a task list for the 4 PRs that fix the known memory leaks. After they are merged this issue can probably be closed, unless anyone knows of any other leaks?

from hazel.

I don't see how forgetting to call OnDetach on layers currently causes any leaks? It is still a bug, but not related to any (current) leaks, so i'll ommit this one from the task list. The others are present.

from hazel.

I'm having the same problem!! Memory leaks just by moving the demo window or moving it outside of the application + it drops a lot of FPS & lags when moving the demo window as you can see.. 16 FPS; That's definitely a bug either in Hazel or ImGui docking branch. p.s I'm using the latest commit.

How did you render the CPU and RAM info?

from hazel.

I'm having the same problem!! Memory leaks just by moving the demo window or moving it outside of the application + it drops a lot of FPS & lags when moving the demo window as you can see.. 16 FPS; That's definitely a bug either in Hazel or ImGui docking branch. p.s I'm using the latest commit.

How did you render the CPU and RAM info?

He is using MSI Burner and Riva statistics

from hazel.

All found memory leaks are fixed. Can anyone re-check if they still happen? Maybe even analyse where they originate from?

from hazel.

Closing this as it is running fine on the current base and all known issues are fixed. If we have any other leaks, we can open specific issues related to them instead of keeping an (old) thread open.

from hazel.

Funny timing, was about to comment that I left Hazel (dev branch) open over the weekend and found it sluggish when I came back. (just a few FPS, usually >>60) I have not yet diagnosed the problem, but worth keeping in mind.

from hazel.

I don't think the dev branch has these fixes implemented to start with even?
Feel free to make a new issue when you come up with some leaks!

from hazel.