koobas.hobune.stream
Memory Leak Help
I wasn't keeping an eye on the profiler and the taskmanager for my Game's memory. Now, when I decided to check, I certainly do have a memory leak. The profiler shows(also the task manager) my memory is increasing by 1MB everytime I run the game. So, I tried everything, including my code check, couldn't figure it out. finally decided to make a backup of the whole game folder then tried deleting all the assets one by one starting with the game scripts until I ended up with only just the first scene. Still the Same leak(1mb increase each time I run my game). I don't know what to do, Anyone out there can solve my problem?
I cannot attach the game, because I don't want to give out all my codes or assets.
The Profiler resets when you Play, so what are you seeing there that suggests a leak? Perhaps post an image of what you think shows a leak.
as I said, the task manager also shows an increase in private memory. Unity crashes when the allocated virtual memory reaches maximum, in my case it crashes when the memory exceeds a certain value every time.
Well, actually you said both show it. But anyway, it sounds like Unity (the editor) leaking, not your game. There is actually no such thing as a memory leak in .NET anyway, since garbage collection works by gathering up "leaked" (unreferenced) objects.
I'm the guy who posted the other question reporting this issue. ;) Like @peter8989 says, the 1mb leaking is definitely associated with the editor. I made a build of the testscene I described in that Question, and the build doesn't have a 1mb leak/run when consecutive runs are observed in the Task $$anonymous$$anager. The 1mb leak/run takes place in the Profiler when run in the editor only, so there is definitely something the profiler is not resetting properly.
$$anonymous$$y original question in this regard was two-fold, though: I added plain integers to a list and then called Clear and TrimExcess on the list in an attempt to free the allocated memory. This did not cause the allocated memory to be freed as expected; it was observed to maintain its memory usage both in the profiler and in the task manager when running builds. This means the second part of my question is likely a bug in $$anonymous$$ono.Net'a GC.
well, i did read your post. Reported this issue to Unity Support with the empty scene I'm getting the leak. Hope to get an answer soon, and will report whatever I hear from them.
I have read a similar issue from another user who was intentionally allocating and deallocating and observing the memory behavior after their deallocation.
http://answers.unity3d.com/questions/153050/memory-management-and-list.html
Since he reported the same amount of memory leak after each execution, I suggested that he quit the game and checked if the memory was freed or not, but he performed a slightly different check.
So, have you checked that unity frees the memory or not after you quit it? I haven't been able to reproduce the issue.
As a side note, I read that instantiated textures aren't destroyed automatically. Does your scene perform any particular texture operations?
it does free the memory, the memory always starts at the same value in my case. I even restarted the computer lol. same result!
but its kinda weird, those two people said they were having the same "1$$anonymous$$B" problem too, seems like a UnityGC bug perhaps?
I actually believe this might be a bug now. I suggest you pack up your test project and report a unity bug. This doesn't seem to be automatically reproducible.
It is. :) Warwick is totally right, here. Remember that a program's allocation of any kind of resource is at the mercy of the OS. Whenever you write "int i = 0", your runtime system runs like a well-trained schoolboy to Windows and says, "Can I have 32 bits, pretty pleeeeease?". That's why unmanaged code written in C and C++ sometimes throws pesky AccessViolationExceptions if you attempt to write to unallocated memory - this is actually the OS telling your program to back off and $$anonymous$$d its own business, because it tried to write into areas of memory reserved by the OS, and it refused your program access. Because the OS is the authority when it comes to GRANTING your program resources, it is also responsible for cleaning up AFTER your program has finished execution. Leaks made by your program manifest while the program runs. Not afterwards.
In your List question, you appeared to believe that allocating a load of memory and then freeing it should result in the memory usage shown in the Task $$anonymous$$anager being unchanged. That might seem intuitively obvious, but it is not true. Programs allocate large chunks from the operating system, then manage handling little 4-byte ints etc. themselves, merely marking something as free (but not necessarily handing it back to the OS). When you think you've just done 100,000 allocations and deallocations, what makes you certain Unity hasn't allocated 4 bytes amongst that for something else (meaning the entire block cannot be reallocated, even if it happened to somehow all be in a new fresh block)?
I am not saying that there is no leak, I'm saying that all the evidence I've heard makes invalid assumptions about memory allocation.
If you go back one step further, you'll see that the "1$$anonymous$$B texture taking 2$$anonymous$$B!!" was also a result of invalid assumptions about memory.
Certainly even a real leak of 1$$anonymous$$B that only happens in the Editor once every Play is rather irrelevant (once people have learned that the OS discards all allocations upon process ter$$anonymous$$ation). If Unity stays running long enough to hit Play 1000 times without freezing or crashing, it probably shows some EasterEgg for all we know...
The analyst replied after he ran the same empty scene, and confirmed that there is a 1MB memory leak. He assured that he will reply after talking with the devs.
