I am learning a car to park itself using the ML framework from unity. I have some problems with unity crashing but my question is based on a potential memory leak.On the first screenshot,We are able to see how much of the memory goes to this process that I have opened. My code is a bit longer for a repost here but I can give you further shots if required.Has anyone experienced something similar before and would you have any ideas about the problem. In my code I keep a list of 4 colliders but I highly doubt it is the source of the problem. It wouldn't reach 8GB no matter what.
First photo
Second Photo
EDIT: Placing some pictures of the code since it is a bit longer.
Code Part 1
Code Part 2
Code Part 3
Code Part 4
Code Part 5
After couple of days I can say for sure that Unity has a serious memory leak in their current ML library.For the people who will stumble upon this thread in the near future , Unity ML 2.0.0 at this time (7/19/2021) has a memory leak. It can result in (FPS dropping,Unity Timeout errors, Unity crashing in general). If you experience similar outcomes, open the memory profiler and let it run for a couple of minutes. You will see the memory increasing linearly. You can dump the memory and see which objects are created excessively.What I did was simply downgrading to ML 1.7.0 Lib.Be careful when setting up the project and don't forget to read the documentation. I hope this is helpful to someone. Have a great day :)
Related
I want to debug which part that consume most of mono memory in Unity because what I saw from profiler is only a chunk said "Mono" something like that and do not know what it is.
I have already done the texture observe in Unity profiler and I do not have a problem with it. (I stated that I used it and saw only mono chunk with high memory) The problem is there must be some kind of memory leak not memory spike because if I play the game long enough, my Galaxy Grand Duo will crash with black texture which is memory used too much. If I saw it in the profiler, it said ManagedHeap and Mono Domain only with large chunk of memory after play the game multiple times.
More information about which platform you are developing for, which tools you are already using, and the reason you are profiling your memory to begin with would be helpful. Without that information I can only suggest the following ...
1) Unity Memory Profiler
I would recommend starting with the memory profiling tools included with the Unity3D editor. You can find out more about these tools here: http://docs.unity3d.com/Manual/ProfilerMemory.html
It sounds like you are already doing this since you have narrowed it down the the "Mono" item from the profiler. This is good, you now know that it is one of your scripts that is consuming the memory.
Make sure you are using the Advanced View. The advanced view of the Unity Profiler will give you more information about which scripts are utilizing your memory.
2) Textures
When it comes to Unity and memory I always start with the textures. It seems like every time I do something with dynamic loading or modifying of textures I end up creating a memory leak. Take a look at your scripts, particularly any that load textures, and try temporarily disabling this logic. Does it help your memory issue?
3) Observe and Optimize
If you aren't able to locate any scripts that seem like they could be causing an issue, I would try observing your game and locating the point where you see your memory spike. Try to identify what logic is running at this point in time. Disable individual scripts and run your scene again. Did this reduce the memory usage? Repeat this process until you locate the script or scripts responsible for your spike. Once you find these scripts you can try re-factoring them until you get the results you are looking for.
I have developed application and all is well. As well, I also keep memory foot print very low.No leaks show during application run. I tested application more than two hour and there is no crashing report. But when i checked application on instruments at that time it's show me following leaks.I have checked my app but there is no such leaking object. "Even I used app continue 12 hour and it didn't crash or stop".
//Here the screen shot of instruments.
///>>>>>>Here, I uploaded latest screenshot of leaks.It may help somebody to understand where the leak is.
// I think it's library file leaks(CoreFoundation)...Please Suggest What to do..
Please help me, This is really screw me up.
Thanks.
Not all of the 'memory leaks', are actual leaks. And some of the reported issues may be caused by Apple libraries themselves. Typically all the singletons, static variables, and some c level variables are 'leaked', but only once and are not considered a threat to memory.
Foundation classes such as NSString, NSArray, etc. are optimized to handle heavy workload. And some objects may be kept in the memory to be reused later. Such as #"".
So unless the issue is accumulating over time, just go for it, submit your app as it is. You still can fix it later, if necessary.
Hey analyze you code using "command+shift+b" and fix all leaks whatever coming after analyzing, submit it to app store. I don't think we can fix all leaks shown by instrument, so better to go with command+shift+b. I think we should use instrument only when getting memory warning and crashes due to insufficient memory.
First let me start off by saying I do not believe I am leaking, but I could be wrong. My issue is that at after my app is done loading I have about 10 - 20 mb of Live bytes according to object alloc, which I am fine with. However, according to activity monitor my process allocation is about 70 - 80 mb, which needless to say is a bit high. To make matters worse when I go on to load the next screen of my app I need to pull more data to build it, which then sends my process allocation up to 100 mb+ or so, need less to say this is much to high and the next action after this causes my app to crash due to low memory warnings. Is there anyway to reduce the process allocation memory?
Belief can sometimes be validated with cold hard data. Have you tried using Leaks? Allocations is another helpful memory profiling performance tool provided by Instruments. The way to reduce memory allocation is to not use as much. ;-)
What are you allocating that takes up 100+ MB? Images? Video?
The question is, are you releasing memory when you're done with it. Instruments can help you answer that question. If you show some code, the community can try to help you troubleshoot as well.
Best regards.
I've just started playing around with opengl es on the iphone the past couple of weeks and i'm looking at refactoring some of my code to use Vertex Buffer Objects(VBO). Before I do though I would like to make sure it'll be worth it. The problem is that afaik the only reason you create VBO's is to shift a chunk of data onto the graphics card so that it doesn't need to be retrieved from system ram when it's used. The iPhone however does not have any dedicated ram that I'm aware of so i'm struggling to see why I would benefit at all from using VBO's. I have seen talk around the internet with conflicting opinions and apple certainly want dev's to use it so there's probably still a reason to use them but just wanted to see if anyone on SO had an opinion to add.
I saw no performance improvement on an iPhone 3G. I moved a bunch of stuff to VBOs, but eventually backed it out as it made it more difficult for me to pursue other performance gains. It's not the quick 25% performance increase that I was hoping for.
I've read somewhere that it can make a difference on the newer hardware (3GS), but I don't have references to back that up.
It depends. (sorry).
Rob didn't see an improvement for his setup, but here is an interesting post that did see a large improvement.
The main reason to existence of VBO's is the presence of static data on 3D models. The first bottleneck you encounter is the slowness of copying data to video memory (by using the unavailable glBegin/glEnd block or glVertexPointer, glBufferData and friends).
Let's imagine the old "flying toaster" screensaver. All toasts are static (changing only the position) - why waste resources copying them every frame from CPU's memory to GPU's? Copy it once with buffers and draw it with a single command. And, depending on how you do animations, even the animated toasters can be described in a static fashion.
My first 2D game I started without VBOs. When I changed to VBOs, no difference (like Rob). But, when I refactored to use more static buffers, FPS gone from 20 to 40. Since my goal was to reach 30, I was satisfied. I had some ideas to refactor even more, leaving everything static, but I don't have time now (game is on review, next one to come).
My app crashes after about 20 minutes with status 101 (Out of Memory, I believe)
Debugging using Instruments - ObjectAlloc and Leaks gives me no clues. The ObjectAlloc graph stays at a nice constant level of around 1 million bytes (1MB), as does the Net # of allocations. I have got rid of all leaks.
I thought it could be something to do with number of threads, but graphing these in ObjectAlloc also shows them to be constant.
Can anyone point me in the direction of another tool, or another avenue of investigation?
Fix everything Clang finds. LLVM Clang Static Analysis
Remember that objects allocated by the system (and that includes things like images and sounds) don't get tracked in Instruments (although the top level retain counts do, of course). So it's feasable that you're loading images, say, which won't contribute much to your memory usage as show, but can drain a lot of actual memory!
If none of this strikes any chords, you could try the subtractive debugging approach - (take a copy of your project) cut out chunks of functionality until the problem goes away or you get the smallest possible thing that reproduces it. That should at least help you to find where the bottleneck is. Admittedly this will be hard (a) because you'll have to wait 20 minutes or so every time you test (but if you make this a background procedure it's not so bad) and (b) because the nature of memory problems is that there may not be one single cause, but a critical mass of smaller causes.
Good luck!
My experiences with Object Alloc have not been that great. It does not always give you the actual memory used by your application.
Instead, use Object Alloc with Activity Monitor. Make sure you use the "Physical Memory Free" and "Physical Memory used" options in the activity monitor. That will tell you exactly how much memory your application is using.
What do you mean by "nice level". It does not rise over time, at all? How much memory total - it could just be the phone needs some memory for some other app and yours is a little too big to stay up.
The error code 101 means that iPhone OS force quit your app. If you're using UIImageViews in your application, be sure to manage the memory on them. I've found that once my application goes over 10/12 MB, the iPhone terminates it.
If you're not using any image views (or large images), then your backend code is eating up too much space.
All I can say is you need to look at your allocation more carefully and manage what views you keep in memory at any one time.
Run your application in Instruments (Run -> Start with Performamce Tool -> Leaks) to see where your memory is getting allocated.
Hope this helps!