Potential memory leak in Isaac Gym

[greg.attra]

Creating and destroying a sim repeatedly in a loop causes a memory leak:

for i in range(10):
    sim = gym.create_sim(...)
    gym.destroy_sim(sim)

printing nvidia-smi shows a steady increase of GPU memory allocation.

is there a proper way of disposing the sim after each loop? this is useful if we need to run multiple experiments / trials with differing configurations

[Abi64]

Interesting! it would also be useful when we need to retrain an agent several times.

[marledu]

Doing this, I inevitably ended up with a segmentation fault. Does this happen for you as well, e.g. if you increase the number of reinitialisations?

Otherwise, my issue could be related to the viewer, as key mappings would also get messed up on reinitialisation.

Eventually, I gave up and ran different configurations via an iteration of os.system calls to a script with different arguments. This could work for your case, as well.

[aart.stuurman]

Possible memory leak

We use Gym to simulate many environments at the same time, multiple times a row, using the Python API. We see memory usage increase on the GPU and CPU. Steps to reproduce: 1 Create a gym object 2 Create a sim 3 Create multiple environments with some actors (100x1 for us), loaded via URDF. 4 Create a viewer 5 Run the simulation (30s for us, dt 0.02, 2 steps) 6 Destroy the viewer 7 Destroy the sim 7.5 possibly destroy the environments, but this is not in the documentation tutorials(?) 8 …

see nvidia comment in this thread. :(

[cwsb]

Same situation - I also ended up with a segmentation fault.

I was benchmarking the simulation performance with varying numbers of environments, and noticed the memory leak after calling gym.destroy_sim(sim). I also ended up just calling the same script multiple times with different arguments.

(I’m using Preview 4)