latest version,got some error

Traceback (most recent call last):
File “E:\MyWork\Panda3D1.9\built\direct\showbase\ShowBase.py”, line 1874, in __garbageCollectStates
RenderState.garbageCollect()
AssertionError: _num_entries == old_map._num_entries at line 713 of e:\mywork\panda3d1.9\built\include\weakKeyHashMap.I
Traceback (most recent call last):
File “main.py”, line 82, in
run()
File “E:\MyWork\Panda3D1.9\built\direct\showbase\ShowBase.py”, line 50, in legacyRun
builtins.base.run()
File “E:\MyWork\Panda3D1.9\built\direct\showbase\ShowBase.py”, line 2979, in run
self.taskMgr.run()
File “E:\MyWork\Panda3D1.9\built\direct\task\Task.py”, line 508, in run
self.step()
File “E:\MyWork\Panda3D1.9\built\direct\task\Task.py”, line 465, in step
self.mgr.poll()
File “E:\MyWork\Panda3D1.9\built\direct\showbase\ShowBase.py”, line 1874, in __garbageCollectStates
RenderState.garbageCollect()
AssertionError: _num_entries == old_map._num_entries at line 713 of e:\mywork\panda3d1.9\built\include\weakKeyHashMap.I

Is there some way we could reproduce this error?

I’m not sure if it’s related but I got something similar (the weakKeyHashMap part at least):

Assertion failed: _num_entries == old_map._num_entries at line 713 of c:\buildsl
ave\sdk-windows-i386\build\built\include\weakKeyHashMap.I
Traceback (most recent call last):
  File "C:\Panda3D-1.10.0\direct\showbase\ShowBase.py", line 1884, in __igLoop
    self.graphicsEngine.renderFrame()
AssertionError: _num_entries == old_map._num_entries at line 713 of c:\buildslav
e\sdk-windows-i386\build\built\include\weakKeyHashMap.I
:task(error): Exception occurred in PythonTask igLoop
Traceback (most recent call last):
  File "main.py", line 196, in <module>
    base.run()
  File "C:\Panda3D-1.10.0\direct\showbase\ShowBase.py", line 2977, in run
    self.taskMgr.run()
  File "C:\Panda3D-1.10.0\direct\task\Task.py", line 508, in run
    self.step()
  File "C:\Panda3D-1.10.0\direct\task\Task.py", line 465, in step
    self.mgr.poll()
  File "C:\Panda3D-1.10.0\direct\showbase\ShowBase.py", line 1884, in __igLoop
    self.graphicsEngine.renderFrame()
AssertionError: _num_entries == old_map._num_entries at line 713 of c:\buildslav
e\sdk-windows-i386\build\built\include\weakKeyHashMap.I

I’m using a recent dev build (a few weeks old now), it crashes when my program starts, but only from time to time (1 in ~100).

I would like more information - are you using threading? I’d really like to reproduce this; even if it’s sporadic, having access to a program which reproduces this would greatly help.

For what it’s worth, you can rest assured that 1.9 doesn’t have WeakKeyHashMap, and therefore does not have this problem, so it shouldn’t be an issue when deploying your application.

I was using threading-model Cull/Draw when it happened, but I can’t share publicly the program at this moment, nor can I make a small sample that reproduces the error, it’s too sporadic.

Maybe I’ll be able to share the code via some private channel, but that was to wait till next week, I’m still struggling to finish it on time.

Fair enough. Let me know if you get more information. Particularly if you also get the error without enabling threading, so I would know whether it is threading-related or not.

I have similar problems. The version of Panda I am using is Panda3D-1.10.0-x64 for windows (thats Panda3D-SDK-1.10.0pre-9868d87-x64) on a windows7 Pro computer. I have threading-model Cull/Draw enabled, which works fine normally in Panda1.10. However, when I use shadows (the ones that were posted by wezu some time ago), it still works great, but when I close the application with sys.exit(), panda crashes. After that, when I restart the panda application there are all sorts of problems, for example:

  • fps is substantially lower sometimes (instead of 60 fps, maybe 30)
  • sometimes this error: AssertionError: _num_entries == old_map._num_entries, the same that was mentioned by wezu

I have to reboot the computer to overcome this.

Its as if memory was not cleared properly. However, when I use RenderState.garbageCollect() or RenderState.clearCache() or cleanup the shadow manager before calling sys.exit() , that does not make any difference.

I also tried loadPrcFileData("", “threading-model None”) to switch off the multithreaded render pipeline and wait a few seconds before calling sys.exit(), but also without results.

There are no warnings, just a crash (ppython.exe stopped working etc).

Is there a way I can find out why panda crashes ?or does anyone have a suggestion ?

Thanks

One thing that can help with the crash on sys.exit is… not to use it, use base.userExit()

I just tried base.userExit() instead of sys.exit(), but it still crases on program exit. If I then restart the application I also sometimes get the following error:

Exception AttributeError: ‘C++ object is not yet constructed, or already destructed’ in ‘garbage collection’ ignored
Fatal Python error: unexpected exception during garbage collection

This only happens after the application has crashed before (on termination) and the program only crashes on termination if I use threading model Cull/Draw (or just /Draw) AND when I use a post-processing effects with shaders (shadows)

I narrowed the problem of the crash at program exit down. When threading-model Cull/Draw is set, the program crases at exit when a shader has been set to a quad, as in:
self.thisInterQuad.setShader(“shadername”)

as part of setting up the FilterManager.
I I set up a FilterManager and don’t set shaders, then it does not crash. I tried to setShaderOff() before the exit, but that does not help.

For example, in the following:

       self.sunFlareManager = FilterManager(base.win, base.cam)
       tex1 = Texture()
       tex2 = Texture()
       tex3 = Texture()
       self.sunFlareFinalquad = self.sunFlareManager.renderSceneInto(colortex=tex1)
       # First step - threshold and radial blur
       self.sunFlareInterquad = self.sunFlareManager.renderQuadInto(colortex=tex2)
       self.sunFlareInterquad.setShader(Shader.load("invert_threshold_r_blur.sha"))
       self.sunFlareInterquad.setShaderInput("tex1", tex1)
       self.sunFlareInterquad.setShaderInput("threshold", threshold)

the setShader function results in a crash when base.userExit() or sys.exit() is called. Any help would be great.

Do you have a testcase I can run?

For what it’s worth, setting “threading-model None” does not disable the render pipeline - it just puts Cull and Draw on the same thread, and calls the thread “None”.

I don’t have a simple testcase but I will make one and let you know. If I replace sys.exit() (or base.userExit()) by os._exit(1) it doesn’t crash and I haven’t experienced errors when the program is started afterwards. I will test it further to see if there are no memory leaks after repeated starts and stops. If that’s the case then this may be a simple workaround.

I have attached a simple testcase, a modified version of RoamingRalph.

I added a few functions to roaming-ralph, and added threading-model Cull/Draw to config.prc. In this example, a filtermanager is added and a few shaders are added. In my version of panda 1.10 64 bits for windows it crashes when the esc key is pressed.
roaming-ralph-test.zip (2.35 MB)

As I mentioned in a previous post, in panda1.10 the engine crashes in my application on program exit when I use sys.exit() or base.userExit(). When I use os._exit(1) it does not crash, but it gives me an open AL error: AL lib (EE) alc-cleanup: 1 device not closed. I thought that solved my problem, but now I get more or less random errors when I start the program:

Exception AttributeError: ‘C++ object is not yet constructed, or already destructed’ in ‘garbage collection’ ignored
Fatal Python error: unexpected exception during garbage collection

Sometimes I don’t get these for days, but on other days I get these errors all the time. Now I found that this is related to the audio manager. I have a number of objects that have an audiomanager and I initialize them as follows:

    audioMgr		= AudioManager.createAudioManager()
    base.addSfxManager(audioMgr)
    self.audio3d = None
    self.mySound = None
    self.audio3d = Audio3DManager.Audio3DManager(audioMgr, camera)
    self.mySound = self.audio3d.loadSfx('/sounds/ENGVOLK.WAV')

The fatal python error occurs after I have initialized around 20 of these objects.
I thought this was all related to the Cull/Draw option, but now I’m pretty certain its because the OpenAL library is not closed properly when using os._exit(1) to close the program. When I don’t use the AudioManager functions, then the sys.exit() does not result in a crash.

Does anyone has a solution on how to close OpenAL explicitly when the program exits ?

Which version of Panda are you using? I thought I’d resolved the fatal Python error.

I used Panda3D-SDK-1.10.0pre-9868d87-x64, and the errors occurred in that version. I think its from august this year. This afternoon I installed Panda3D-SDK-1.10.0.pre-bac5401-x64 (the most recent one) and tested it a couple of times, and haven’t seen the fatal Python error yet. So maybe its resolved then.

Thanks.

I’ve just checked in some fixes. I still don’t understand why the WeakKeyHashMap assertion triggered when not using threading, and I still cannot reproduce it, but I think the assertion should be gone now. Not saying it’s completely bug-free, but that’s what it’s a development build for :wink: (1.9 shouldn’t have this issue).

If you are getting this on Linux, I really need a backtrace on this to get further, so I urge you to enable core dumps (“ulimit -c unlimited”) and set “assert-abort true” in Config.prc to chuck out a core dump as soon whenever the assertion triggers, which you can open with gdb to get a stack trace.

As for the crash on exit with threading, I do see a crash, with an assert:

Assertion failed: _total_size == 0 && _count == 0 at line 36 of panda/src/gobj/bufferContextChain.I

Do you see this assert, too? I’ll see if I can investigate further.

As for OpenAL: yes, the OpenAL library has a weird atexit handler that errors if you don’t destroy the audio manager before exit-time. ShowBase has an atexit handler that calls base.destroy() which destroys the audio manager, which is normally sufficient. However, if you call os._exit(1), ShowBase’s atexit handler won’t run, but OpenAL’s will (since it is implemented in C).

So, if you insist on using os._exit(1) instead of sys.exit(), be sure to call base.destroy() first. If you create your own audio managers, you have to call shutdown() on your audio manager before exiting in order to satisfy OpenAL.

I am running in windows 7 64 bits. I don’t see that assert. There’s no assert at all. When using sys.exit() the rendering just crashes without any warning or error.

I tracked down another shutdown crash in the cleanup of Cg shaders that occurs in the multithreaded pipeline, which seems like it matches your description.

The fix is in the latest buildbot release and will also be part of 1.9.1. Thanks for reporting!

Yes, that solved my problem. Thank you!