can't find memory leak

Looks like the pheromone is being freed, but not the shape object it creates, pherShape!

- jon

Ok, that helped a bit, but the problem hasn't disappeared. I have checked that the number of spheres isn't increasing by printing out the total number of spheres. How does the memory management in breve works? Are the objects tagged for deletion and deleted later or are they deleted immediately? Maybe I can issue a method call to flush the garbage? It's possible that that time is too long, because I'm creating a lot of objects ( around 4000 objects for 240 simulated seconds :? ).

Objects should be deleted at the end of the iteration step, which means it basically happens immediately.

Have you checked for leaks in other object classes? It can be useful after each run to print out the total number of objects just to check that there's not something else that was overlooked.

If you're confident that it's not a memory leak in your own code, then you can send me the simulation and I can try to determine if there's a leak in the engine itself.

- jon

I followed your advice, and I managed to find some more leaks. The number of objects stays the same now after each run. But still the memory usage increases a lot. I use a plugin, but with valgrind I didn't find memory leaks in my library (from before the memory leak squashing session). However, I found some memory leaks (minor ones) in breve. I have the valgrind log on my webspace http://m0219842.kuleuven.be. You can also find my code there. The plugin is in evoneural, build instructions are supplied in the INSTALL file. The plugin is only tested on linux, but I don't use any specific linux things. My breve simulation is in the directory saint. You can start it with the command "breve_cli PheroEvoSimController.tz". It might be a bit of a hassle to set everything up, so don't feel forced to do so :D . Anyway, already thanks for your help, I will continue searching the answer :D

I did some more tests, and I think that the problem must be with breve. I have checked my own plugin, and no memory leaks are supposed to be in it. The number of objects stays constant after each run. Moreover, if I don't drop pheromone, I don't have such a memory use. If I however use pheromones, I have that enormous memory consumption. If you want I can give you an account on my pc to test it, with in a directory set up the project.

I ran into similar problems and added a "notvisible" state as a holding place for "destroyed" objects. Before creating a new instance, first see if there any in the "notvisible" pool, and if so reuse them. If not allocate a new instance.

Take a look at the Fountain demo.

David

Thx, that did the trick. My memory use is finally under control :) . Does there exist a method to tell breve not to handle collisions for a specific object? Now I have built in an extra check to see if it's visible or not, but maybe I could get it faster by disabling the collision handling.

I assign large random coordinates to my "notvisible" objects, but I am a little concerned that this is messing up the get-neighbors search. Not sure what would happen if you set neighborhood size to zero. Hard to worry too much about this because I assume that the memory leak is a temporary situtation that will eventually be tracked down.

David

Even without the memory leaks, the technique djstates suggests is a good idea since it avoids the overhead of adding and removing generic objects.

For the sake of getting rid of memory leaks in the breve engine, however, it would be useful if you two could email me your simulations so I can track down and remove any problems.

Thanks,

- jon

Sorry for the long delay. I'm busy writing my thesis, so... The code is written for Linux, instructions are provided in README and INSTALL files. This is the fixed version, when using the pool. Changes are however fast to make:

In PheroEvoSimController.tz: change the method get-pheromone to always return a new Pheromone instance

In Pheromone.tz: change the implementation of the method dissolve to destroy itself

You can download it here: http://m0219842.kuleuven.be/source.tar.bz2

Hi,
before I try this out, can you test the code with the new beta at http://www.spiderland.org/breve_2.4_betas? I fixed some major memory leaks since this was first posted.

- jon

jk wrote:Hi,
before I try this out, can you test the code with the new beta at http://www.spiderland.org/breve_2.4_betas? I fixed some major memory leaks since this was first posted.

- jon

I can't run my simulation with the latest svn checkout. I used the newest slBrevePluginAPI.h from svn to compile my plugin.

$ breve_cli PheroEvoSimController.tz
cannot convert type "(null)" to type "pointer"
error in assignment
... error in file "EvoSimController.tz" at line 54
NULL pointer passed as argument 0 to internal function deleteEA
... error in file "EvoSimController.tz" at line 44

The same code does run with breve 2.3.

Hi, my evolution simulation has also been affected by memory leaks, which cause it to slow down to 1/2 - 1/3 the speed after several hours running. The object count stays constant, but since my simulation is several thousand lines long, I made a test case to verify this:

@use Control.

Controller MemoryLeakTest.

Control : MemoryLeakTest
{
    + variables:
        thing (object).

    + to init:
        (self execute command "open /Applications/Utilities/Activity\ Monitor.app").
        self disable-freed-instance-protection.
        thing = new Thing.
        thing set-value to 123.
        
    + to iterate:
        i (int).
        for i=0,i<100,i++:
        {
            free thing.
            thing = new Thing.
            thing set-value to 123.
        }
        #print "Objects:",|all Objects|. # Uncomment this line to verify that the Object count remains the same
}

Object : Thing (aka Things)
{
    + variables:
        value (int).
        #filler1, filler2, filler3 (500 ints). # Uncomment this to verify that the size of the object has no impact
        
    + to set-value to val (int):
        value = val.
        #filler1[499] = val. filler2[499] = val. filler3[499] = val. # Uncomment this to verify that the size of the object has no impact
        
    + to get-value:
        return value.
}

The leak is still present in the last version of the Mac OS X 2.4 beta (2006/04/27).