Possible memory leak in scene geometry data structures

[stukowski]

I suspect a memory leak in OSPRay's scene geometry handling. Hope you can help.

It would be great if you could take a look at the attached minimal test case, which reproduces the issue. I originally noticed a constantly growing memory footprint in my application code, which uses OSPRay for rendering an animation with changing scene geometry. I then managed to boil it down to this very simple and self-contained test case.

The test code creates a "mesh" GeometricModel consisting of 10,000 triangles. In a for-loop, it then repeatedly wraps the GeometricModel in a Group, wraps the Group in an Instance, which is then inserted into a new World. Then all objects get released at the end of the loop and the process repeats.

During each loop iteration, the memory footprint of the running process grows by several megabytes, which can be observed in the OS task manager, suggesting that the world's internal data structures do not get properly released. Note that the minimal example does not involve any rendering, just setting up the world.

• Tested with OSPRay master branch and v2.1.0.
• ospcommon 1.3.1
• Embree v3.9 and v3.10
• Operating system: macOS 10.15.4

test_case.zip

EDIT: I should mention that I already made my own unsuccessful attempt to debug the problem (by inserting a couple of print statements into the OSPRay code). But I could not identify the origin of the memory leak. I got the impression that all OSPRay class destructors get properly called upon releasing the World object. So the actual problem may lie deeper, perhaps inside the Embree library or the code building the acceleration data structures.

[miroslawpawlowski]

Thank you for the info, we have done some experiments and can confirm that indeed there exists problem with memory leaking. Please expect a fix soon.

[stukowski]

Thank you.

While you are at it, I would like to ask you to take a closer look at this particular code block:

https://github.com/ospray/ospray/blob/master/ospray/common/Data.h#L291-L302

I am not 100% certain, but during my own bug search, I got the feeling that the ad-hoc Data object created by this code may leak. Note that this problem is not related to the memory leak reported above, but it should probably be fixed as well. The problem occurs when assigning a single OSPMaterial to the material field of a GeometricModel. It can be worked around by first wrapping the material in a Data array of length 1 before assigning it to the material field.

[dempo93]

Confirmed with

• ospray master c902dca37f165e01365e51b6bba107dcc53a6842,
• openvkl 0.10
• rkcommon 1.4.2
• embree 3.11.0

compiled with gcc10 on ubuntu 18.04

I have project which is very similar to the minimal example provided by @miroslawpawlowski, the problem seems to be the same. Valgrind finds:

Indirect leak of 240 byte(s) in 5 object(s) allocated from:
    #0 0x7f90b05febb7 in operator new(unsigned long) (/usr/local/lib64/libasan.so.6+0xadbb7)
    #1 0x7f90ae3dce6d in rtcSetSharedGeometryBuffer (<embree_root>/lib/libembree3.so.3+0x205e6d)
    #2 0x7f90a6389d27 in ospray::Mesh::commit() (<my_project_root>/ospray/lib/libospray_module_ispc.so+0x129d27)