A memory leak when removing and adding an image sequencely?

Solar2D General Questions/Discussion
#21

I’m also experiencing this. I’m using the latest daily build (as of morning of March 7) and I notice that everytime I change a scene, print( garbagecollect(“count”) ) continues to increment. With MANY different “scenes” in my app, this eventually climbs to an unbearable amount of memory being used up.

Texture memory is stable, however.

Any updates on this issue? Also… to re-state a question mentioned a couple posts before me, does the scaling-down of the object before removal really help? [import]uid: 7849 topic_id: 4295 reply_id: 26747[/import]

#22

I tried the scaling trick in my project to no avail.

With some of my heavier scenes, I am seeing a HEAVY increase when printing the output of collectgarbage(“count”) so this is going to cause major probs for me if it’s not addressed.

My texture memory looks great. Everything seems to work; however, the actual memory usage based on Lua’s output just climbs and climbs and climbs. [import]uid: 7849 topic_id: 4295 reply_id: 26750[/import]

#23

@ jonbeebe

I’ve mentioned the scaling-down just as a strange angle to this issue (which might help the Ansca staff to locate and fix that bug).
I don’t think it should serve as a workaround (even if it works, and as you mentioned it doesn’t).

I wasn’t able to solve or to find any workaround since.
I agree with you that this is a major issue, preventing us from developing a game with many heavy scenes.
Personally, this is really frustrating, since my current game is a nice platform game, with many scenes.

As you can see (post #9), Tim from the Ansca staff has filed a bug on this issue a few months ago.
I hope that now (with your post added to this thread), the Ansca staff will be able to update us on this issue…
[import]uid: 9536 topic_id: 4295 reply_id: 26753[/import]

#24

I wasn’t able to reproduce the original bug (from the code sample provided above) in build 302 or later. What builds are people using? Can someone provide another test case that repros the issue again?

Thanks
Tim [import]uid: 8196 topic_id: 4295 reply_id: 26996[/import]

#25

@ez123: Can you retest your code in build 312 or something past 307 (as Tim describes) to confirm if the “bug” is still present or not?

-Thanks! [import]uid: 7849 topic_id: 4295 reply_id: 27371[/import]

#26

I just ran the code in build #311 and the memory usage doesn’t change. When I run it in build 243 or 268 (the last released build) the memory increase with every tap.

I suspect some other memory-related bugs were fixed that also fixed this problem.

-Tom [import]uid: 7559 topic_id: 4295 reply_id: 27374[/import]

#27

@Tom: That’s great to hear! Sounds like everything’s been resolved in one of the later builds :slight_smile: [import]uid: 7849 topic_id: 4295 reply_id: 27399[/import]

#28

I did some testing this morning and figured out why scaling the image (or using a different image) doesn’t cause the memory leak. The reason (or bug) is when the blue touch rectangle overlaps the background image (default.png). Touching the blue object where it overlaps the background image causes the small memory leak. I scaled the Default.png image to 50% and moved it up so it wasn’t under the blue object and there was no leak. When I drop it down so half of the image was under the blue object, the memory leak only occurred when touching the area where the two objects overlap. It looks like the touch event is also being sent to the background image object even though it doesn’t have a listener. This may be related to object being removed and created within the touch listener. Not really sure.

Build #268 (last released build) shows the memory leak.
Daily build #277 crashes simulator when touching the overlapped area.
Daily build #311 shows no memory leak when touching the overlapped area.

In looking at the build history there were a few fixes for a group bug and memory leak associated with Physics addBody which may be related. The bottom line is the problem is fixed in the latest daily builds and will be available to everyone in the next formal release.
[import]uid: 7559 topic_id: 4295 reply_id: 27408[/import]

#29

Wow, great work Tom! It’s great to hear that the bug is “officially” squashed though :slight_smile:

In the next iteration of my cleangroup.lua module, I’ll omit the scaling code. [import]uid: 7849 topic_id: 4295 reply_id: 27411[/import]

#30

Great to hear that guys :slight_smile:
Good to know that one of the most disturbing bugs was resolved. [import]uid: 9536 topic_id: 4295 reply_id: 27434[/import]