Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (777)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [LibGDX] Memory leaks are killing me......  (Read 6557 times)
0 Members and 1 Guest are viewing this topic.
Offline Luca91

Junior Newbie





« Posted 2014-09-08 17:22:01 »

Good evening,
first of all, I'm new here.
I'm having some serious issues with some memory leaks. Let me expalin in detail:
My game (it is an android game) is composed of 3 game screens, on is the main menu with the option tab, one is the pre-match menu, and the last is the in-game screen.
My game is working perfectly but crashes very often due to what I think are memory leaks.
When my game crash, I don't get any error message from the game log, but in the general android log I see:
Quote
09-08 17:23:45.718: E/InputDispatcher(376): channel ~ Channel is unrecoverably broken and will be disposed!

When I switch from a game screen to another, I always call .remove() to my objects (like buttons, labels etc) and I've a list of disposable items that I just dispose using an iterator.
I switch from a game screen to another using: game.setScreen(new gameMenu(game, actionResolver));
Now I've also some questions:

1) is there a way to completely destroy the old screen class when I switch game screen ? for example, to completely remove  gameMenu() when I switch to gamePrematch(), since I don't need gameMenu() anymore. I'm asking this because in that way would be simple to avoid memory leaks, because if I'm not wrong, when the class will be destroyed, the GC will collect every variable that existed in the class.
2) in the ingame screen, I've some functions that declare some images in that way:
1  
 Image player = new Image(new Texture(Gdx.files.internal("data/player.png")));

when I call player.remove() will the GC clean also the texture object ??
3) Maybe my problem is not releated to memory leaks and I'm missing something ?? what do you think about ??

Thank you very much
Offline Warden
« Reply #1 - Posted 2014-09-08 18:09:28 »

Have you tried the debugger to narrow down the block(s) of code that it breaks at?
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #2 - Posted 2014-09-08 18:12:15 »

As far as I remember there is a destroy method on almost all objects Smiley Image::destroy

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Luca91

Junior Newbie





« Reply #3 - Posted 2014-09-08 18:25:06 »

As far as I remember there is a destroy method on almost all objects Smiley Image::destroy

the destroy method doesn't exist in libgdx objects. They have the remove() method..

Quote
Have you tried the debugger to narrow down the block(s) of code that it breaks at?
it breaks when it reach a certain number of objects ( logged with DDMS and heap tracker)

it seems that the GC doesn't clean some objects
Offline richierich
« Reply #4 - Posted 2014-09-08 18:31:51 »

Could be a timing thing if it doesn't happen every time. Maybe something like there's still events coming in from the input - finger-up or something - when you remove one screen, and sometimes there's time for them all to get handled and sometimes there's not, in which case you've removed the object but android still tries to dispatch an input event to it. Would depend what kind of threading you're doing I guess. I don't know much about android event handling.
Offline Luca91

Junior Newbie





« Reply #5 - Posted 2014-09-08 18:36:29 »

It is not a timing issue because it always crash when reach a certain number of objects in the heap
Offline UprightPath
« Reply #6 - Posted 2014-09-08 19:07:20 »

It's dispose() that LibGDX uses. That releases the texture contexts and everything.

Pages: [1]
  ignore  |  Print  
 
 

 
hadezbladez (335 views)
2018-11-16 13:46:03

hadezbladez (177 views)
2018-11-16 13:41:33

hadezbladez (336 views)
2018-11-16 13:35:35

hadezbladez (82 views)
2018-11-16 13:32:03

EgonOlsen (2175 views)
2018-06-10 19:43:48

EgonOlsen (2203 views)
2018-06-10 19:43:44

EgonOlsen (1376 views)
2018-06-10 19:43:20

DesertCoockie (2008 views)
2018-05-13 18:23:11

nelsongames (1646 views)
2018-04-24 18:15:36

nelsongames (2297 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!