If it goes up every reload then you are right to suspect a leak of some sort. I can play my game for weeks and it never leaks. It sits at about 2MB of system memory. Only rising and dropping because of particles being created and removed.
If you want others to take a peek, post some code for loading the level initially and then the reload code. Maybe someone can see something that could be causing it. [import]uid: 56820 topic_id: 34969 reply_id: 139084[/import]
This is not a leak. The framework will reuse memory that is given to it. It seems that the underlying Corona SDK engine does not free memory related to the scene, perhaps for performance purposes as allocating additional memory can be expensive. Here is the proof:
Regards,
M.Y. Developers [import]uid: 55057 topic_id: 34969 reply_id: 139085[/import]
You could also try M.Y. Developer’s Corona Profiler. It could help you pinpoint where the memory is coming from. I think it’s like $10. [import]uid: 56820 topic_id: 34969 reply_id: 139086[/import]
I’ll definitely take a look at the profiler.
Thank you very much for open my mind on that issue! 
[import]uid: 116181 topic_id: 34969 reply_id: 139089[/import]
Thanks for the suggestion!
Here are a few tips about finding memory leaks in general. The first thing you should do is make sure you have a memory leak in the first place. It can be difficult to tell if an increase in memory is a leak or just an innocent memory allocation. In order for it to be a leak, the memory must increase reproducibly. An easy way to think of it is to picture your app as a series of events. Naturally, there are events that should “undo” eachother in a memory standpoint. A common one is transitioning between scenes or going from the game scene to the main menu scene. The first few times the event occurs the memory will increase due to allocation but if you go back and forth a few times the memory should remain constant. If there is a leak, you should see a linear increase even after say 5 repetitions.
So now you have found a memory leak between the main menu and scene A. This is where profiler can help you the most. All you would need to do is call diffsnapshot() at some point during the transition from main menu to scene A. This means you can put it when scene A loads or when scene A unloads. Now, with mode 4 running you repeat the steps illustrated above and after a few repetitions a steady state emerges. Mode 4 will tell you the exact tables that are increasing from snapshot to snapshot so it should help you narrow down the problem.
Finding and fixing leaks is a difficult process and sometimes you need to ask yourself: How long will my program even be running? Obviously if you are making a web server you cant have even a single byte of leaking but for a game that the user plays for 20 minutes it might not be much of an issue for a small leak.
Regards,
M.Y. Developers [import]uid: 55057 topic_id: 34969 reply_id: 139094[/import]
@M.Y.developers: Magnificent clarification!!
I am very persistent and I always like to dig deep until i understand what’s going on, because i don’t want to produce a low quality / buggy app, like any of you, I guess
PS:
I will buy the profiler =P [import]uid: 116181 topic_id: 34969 reply_id: 139107[/import]
I think the problem you are running into is that you’re not giving the garbage collector time to work. I don’t think in the real world you’re going to be allocating 1000 display objects. Each one returns a pointer to a table of information. When you call the objects removeSelf() function, the texture memory is deallocated, but the table containing the X, Y of the object remains. This is why you have to “nil” the object.
But in your test you are immediately (within microseconds) overwriting that nil and when the GC runs, the pointer is only nil for the last object. This will slow your loop down considerably put force a garbage collection immediately after you nil the object. [import]uid: 199310 topic_id: 34969 reply_id: 139108[/import]
