Possible memory leak in igLoop()

General Discussion
1

Hi, community.
My teammates and I find a memory leak problem in igLoop(). The memory usasge is normal when our program runs in “none” mode and “offscreen”. However, when we use “onscreen” mode, the memory usage increases rapidly, like what shows in the following graph

leak
leak1536×757 26.3 KB

After excluding the bug in our program, we finally find that removing the “igLoop” in taskMgr solved this problem. The memory usage is stable after doing that.

remove_ig
remove_ig1260×540 19.5 KB

We don’t think the memory leak in igLoop() is a common problem, since panda is really mature and igLoop() implements the most important render task. And we are not familiar with the render process. So is there some “buffers” used to cache data? When the “buffers” are filled up, the memory usage will not increase. Besides, we use 1.10.5 edition with multithread render (cull/draw), and I saw that in 1.10.6 edition a memory leak problem is fixed. I don’t know if the problem is what I encountered.

2

hummm, the multi-thread rendering (“threading-model Cull/Draw”) raise this problem !!

3

You should open up PStats and drill down into the memory charts. It will let you know which types in Panda are taking up an increasing amount of memory.

igLoop includes the base.graphicsEngine.renderFrame() call, which encompasses a lot of things, including various caches. It would be more useful to find out which part of the scene needs to be hidden/stashed in order not to have this problem.

Before you do any of the above, you must upgrade to 1.10.7. 1.10.5 contains a number of bugs (including memory leaks) that have since been fixed, as well as an issue in PStats’ memory tracking.

4

Thanks for your quick reply! Pstats is really a good tool! I even don’t know it can do this!! I upgrade my panda edition to 1.10.7 and follow your instruction to use Pstats. I find the memory leak in multi-thread rendering still exists.
image

Fig. 1 using multi-thread rendering
loadprcfile “threading-model Cull/Draw”

1608396037(1)
1608396037(1)1440×741 34.9 KB

Nomal memory usage with one thread to do cull, draw, render
Fig. 2

ok
ok1440×741 54.4 KB

It seems that something in MMap does not release. And is the MMap mipmap? (I am a newbee to computer graphics :sweat_smile:)

5

It means “memory map”. This may be a bug in Panda3D. I’ve filed an issue report:

6

Thanks for your help :grinning:! Actually, we find another bug in BulletVehicle. The api get_current_speed_km_hour() of BulletVehicle() returns a negative value sometimes. We find the source code of this api is getRigidBody().node().get_linear_velocity().length() * 3.6 in BulletEngine project. And then we replace the method of getting vehicle speed in our program from get_current_speed_km_hour() to self.chassis_np.node().get_linear_velocity().length() * 3.6. When we use the same test case to test the new method, the value returned is positive and almost equals to abs(get_current_speed_km_hour()). I assume that panda3d only wraps Bullet, and maybe I should report this to Bullet community.

7

Good news: I’ve tracked down the memory leak and checked a fix into the source code repository. I plan on making a new Panda release next week which will include the fix. Thanks for bringing it to light!

It’s typical to create a new thread when you have a new question. In this case, however, you’re right that Panda is but a narrow wrapper over Bullet, and there might not be much to do on the Panda end, other than perhaps upgrade the Bullet version we build against.

3 Likes