Memory isn't freed when I close my program

edited December 2017 in Python Mode

Hello, I'm currently programming a little game and for that i need to load some image and musics that will be used very often. The fact is that i got two problem: - When the program close, no matter the reason, the memory isn't freed and so every time i run it uses more and more ram. For example i can't run it more that two times without manually killing the process in windows which is a bit frustrating when i must fix 50 bugs or so. - The other problem is that processing with python uses a lot of memory compared to the total size of the file that i load: 2.5 giga of ram for only 40mb of assets. I don't know if i have to post my code because nobody would have the patience to read 380 lines of it. But if you want to see it i can give it. Finally, i hope those issues are fixable and sorry for my bad english, i'm french.



  • We'd need to see your code. All 380 lines of it if you like. But at minimum the code that is loading your data & the function it is contained in.

  • Ideally the smallest program you can share that still exhibits the bug. Trying to quickly cut it down to a still-bugging short program is also a great way to narrow down the problem!

  • edited December 2017

    Ok, so here is the part of the code where i load the data:

    def setup(): global lis_carte global lis_carte_collision global lis_background global trolmo_r_1 global trolmo_r_2 global trolmo_r_3 global trolmo_l_1 global trolmo_l_2 global trolmo_l_3 global trolmo_tab global game_over global trolmo_ball_tab global music_1 global music_gm global vie_trolmo_tab size(1280,720) carte_1=loadImage("map_monde.png") lis_carte=[carte_1] carte_1_collision=loadImage("collision_monde.jpg") lis_carte_collision=[carte_1_collision] background_plain=loadImage("Plain.png") lis_background=[background_plain] game_over=[loadImage("game_over_continuer.jpg"),loadImage("game_over_quitter.jpg")] # import ressource Trolmo trolmo_r_1=loadImage("trolmo_right1.png") trolmo_r_2=loadImage("trolmo_right2.png") trolmo_r_3=loadImage("trolmo_right3.png") trolmo_l_1=loadImage("trolmo_left1.png") trolmo_l_2=loadImage("trolmo_left2.png") trolmo_l_3=loadImage("trolmo_left3.png") trolmo_tab=[trolmo_r_1,trolmo_r_2,trolmo_r_3,trolmo_l_1,trolmo_l_2,trolmo_l_3] trolmo_ball_r_1=loadImage("boule_de_feu_R1.png") trolmo_ball_r_2=loadImage("boule_de_feu_R2.png") trolmo_ball_r_3=loadImage("boule_de_feu_R3.png") trolmo_ball_l_1=loadImage("boule_de_feu_L1.png") trolmo_ball_l_2=loadImage("boule_de_feu_L2.png") trolmo_ball_l_3=loadImage("boule_de_feu_L3.png") trolmo_ball_tab=[trolmo_ball_r_1,trolmo_ball_r_2,trolmo_ball_r_3,trolmo_ball_l_1,trolmo_ball_l_2,trolmo_ball_l_3] # vie_1=loadImage("vie_1.png") vie_2=loadImage("vie_2.png") vie_3=loadImage("vie_3.png") vie_4=loadImage("vie_4.png") vie_5=loadImage("vie_5.png") vie_6=loadImage("vie_6.png") vie_trolmo_tab=[vie_1,vie_2,vie_3,vie_4,vie_5,vie_6] music_1=minim.loadFile("Town - Sunny Village.mp3"); music_gm=minim.loadFile("HB_Starter_-_Fantasy_-_Sad.mp3")

    When i want to use a picture i use image() like in this example:

    background(background_aff) image(carte,x_aff_map,y_aff_map) image(trolmo,x_aff_trolmo,y_aff_trolmo) stroke(0,150,150) for ball in lis_fireball: if ball[3]==1: image(trolmo_ball_r,ball[0],ball[1]-(ball[2]-y_aff_map)) if ball[3]==-1: image(trolmo_ball_l,ball[0],ball[1]-(ball[2]-y_aff_map)) #ellipse(x+65,y+105,1,1) image(vie_trolmo_tab[vie_trolmo-1],10,10)

    This portion is called in the draw() function.

    The other parts are mostly collisions detection with lists of position and other minor things that don't seem to be buggy. But if you can't find anything here i will provide them.

  • edited December 2017

    But if you can't find anything here i will provide them.

    No no, try providing an MCVE

    If you put the code that you just pasted into a complete minimal sketch with setup and draw, and you press run, does it have the bug, or not? If not, you haven't given us enough to look at. If it does, you have.

    If it doesn't have the bug, then just follow TfGuy44's advice and post all 380 lines.

  • Ah sorry i'm a beginner so i still have to learn. So I've tested with only the setup() function that i gave you and the result is that memory is still not freed when i close the program. When i load it multiple times without manually cleaning the process it goes up to 2.3g and my laptop nearly crash. If i just load it once it uses 1.3-1.5g. It is really a problem for me because i will need to load more images and music to implement other features.

  • Okay, great. This could still be a bit hard to test for somebody who doesn't have your specific image and sound files.

    If you run it with just the images, does it still not free the memory? If you run it with just the sound?

  • Ok after some tests i discovered that the huge memory consumption is due to the map which is a 23248*2592 png file and the collision map of the same size. Processing uses 600mb for each of them. The question now is why? Because the total size of the files is only 43mb. (also memory isn't freed no matter what i try)

  • Briefly -- Processing loads the image data into memory so that you can manipulate it.

    Unless you have a 23000 pixels wide screen, you really don't need to load (mulitple) 43MB png files. Try tiling, for example.

    The memory-isn't-freed part sounds like a bug.

  • A 232482592 bitmap is 602588164 bytes per pixel which is 241 million bytes or so. The size of the PNG file is not relevant. I wonder where the additional 360 million bytes are coming from.

  • Yes that's what i was thinking to. If the color of a pixel is a 32 bit information that means that with the size that i use, it should only use ~230mb per image. Even if you consider that this is a 64 bit information it doesn't fit.

  • it possible that you are ever unintentionally creating additional copies of your PImage lists -- e.g. by adding them together with + or using list()? Hard to know without seeing the code.

  • No i don't think so, it uses 600mb even if i just load the image.

  • I have seem this problem before... You can notice it with big images. I was using a 4608x3456 for the record. If time permits, I will dig the example or create an mcve...


Sign In or Register to comment.