Memory problem when using resetFiltering

Hi,

I am using PhysX 3.3.1 for a somewhat unusual application which involves repeatedly restoring a particular scene state and rerunning the simulation with slightly different conditions. For this application it is important that the results are very reproducible, i.e that if I restored the state twice and ran the simulation with the exact same conditions twice, the results should be as close to identical as possible. I have tried various methods to achieve this, but the most reproducible approach I have found is to serialize the parts of the scene I want to restore, then remove them from the scene and deserialize their stored states. To avoid discrepancies between simulation runs, I have also found it necessary to call resetFiltering on actors which might experience contacts, to force fresh evaluation of contacts each time.

I have noticed that the memory usage of my application increases more or less linearly over time. Looking at memory usage in the PVD, almost all of the memory seems to be allocated by PxsAABBManagerAux.h:1503

http://i.imgur.com/sZ1EzsR.png
http://i.imgur.com/U4P5B2O.png

Removing the call to resetFiltering eliminates the memory problem. Is it possible there is a memory leak associated with resetFiltering?

At the start of my program, I set up a series of states, call resetFiltering, then serialize the states. My scene contains 1 aggregate containing an articulation with 23 shapes, and a ground plane. If I call resetFiltering on all the actors in the articulation, on setting up the 5th such scene state, I get a warning from PxsAABBManager.cpp (541) that I have more than 128 shapes in my aggregate. Similarly, if I only call resetFiltering on the 2 actors (with 1 attached shape each) which might undergo contacts, I get this warning on setting up the 53rd scene state. This suggests to me that there might be some spurious shapes (and AABBs) being created and not cleared up, since

23 original shapes + (23 additional shapes for each call to resetFiltering) * 5 = 132 > 128
and 23 + 2 * 53 = 129 > 128

At the same time, iterating through all the actors in the aggregate and counting all the shapes gives the expected value of 23, and calling getNbShapes() from the PxPhysics instance gives the expected value of 24 (including 1 for the ground plane).

Any help with this problem would be much appreciated.

Best wishes,

David

Hi,

I made a mistake in my previous post - removing the calls to resetFiltering does not eliminate the memory problem. My current thinking is that the problem is probably related to repeatedly serializing and deserializing the scene state. Perhaps I am not properly clearing up the chunk of memory I am using each time to load the serialized data.

I have found a workaround for the time being - releasing the PxScene and rebuilding it after every few thousand scene restorations keeps the memory usage low. Not very elegant but it does do the trick. It would still be nice to better understand what’s going wrong, but it’s not very urgent now I have a working method.

Best wishes,

David

Thanks, we’ll look into it. If you could reproduce this problem in a Snippet sample application, as included in the SDK, it would help us speed things along.

Thanks,
Mike

Hi Mike,

thanks a lot for your response.

I have modified the hello world snippet application to make a minimal repro here

It needs to be compiled with /EHsc. I have tested this on my machine and I am seeing the AABB memory problem with this code.

There are a couple of areas of my code I am not sure about, they might be the best place to look first for problems. In storeSceneState(), to create a collection containing the aggregate and its contents I use the function to create a collection from the scene and then go through the contents of that collection looking for aggregate and articulation objects, which is pretty clunky but I couldn’t see a better way to do it. Similarly, I don’t think my code for releasing the existing aggregate and all its contents in restoreSceneState() is very neat. I’m not sure if one of these might be causing my memory problems, but even if not I would appreciate any suggestions on better ways to do these steps.

Thanks for your help,

David

Hi,

I’ll download it and have a look, thanks.

–Mike

Hi Mike,

I am also sometimes (it seems to be intermittent) seeing a crash during the simulate call when it tries to allocate memory. When I did some debugging of the allocator, I found that a large negative amount of memory was being requested. I noticed that in this other thread

https://devtalk.nvidia.com/default/topic/789764/

you asked about deserializing from binary. Is there a known problem with deserialization?

This problem occurs in my main code, but does not appear to happen in the sample I uploaded.

Thanks for your help,

David