Phantom 'Zombie Object' Warning

I recently discovered that a project of mine was causing blender to crash to desktop without any error message when moving in and out of its main menu scene, the apparent reason being the ‘enemy’ object. Upon reflection, I had noticed it being referenced in “Zombie Object” warnings on the console when debugging.

Thinking this was the problem, I sifted through the forum a bit, and found out that the warning is standard when an object with a debug property is deleted. Sounds all good and well, and rather easy to fix, but…

  1. The object causing the trouble has no properties marked for debug (no objects do),
  2. No object in the scene experiences deletion during testing,
  3. The warning appears even when the ‘enemy’ object remains on a hidden layer, and
  4. Zombie Object warnings are said to have no effect on performance or stability, yet seem to have at least some correlation to the crash-to-desktop event.

Perhaps I have not grasped the full definition of the “Zombie Object” warning, but I can’t see any way in which this object is causing this much fuss. The only current workaround is deleting one cross-object actuator that the enemy needs to operate.

Any tips on how to diagnose or fix the aforementioned, or create a workaround, would be appreciated. I plan to upload a demo soon.

Edit: Okay, here’s the file: TGTEAGs_Iteration3.blend (1.53 MB)

Cause:
The zombie object error means something accesses a game object that does not exist anymore.

Issue
The error message is a recover from an erroneous situation. It is an indicator of a design issue. It is not supposed to be part of the regular process flow. You should fix the process flow as soon as you know the situation. If you do not, something else will not work which requires the requested object (follow-up error).

Possible Situations:
The debug messages are just one situation. Obviously when it is not enabled … this situation does not apply. (this situation indeed has no further side effects)

Accessing objects from Python code. In this case you typically get a stack trace, that will help you … I guess this is your situation.
To analyze your situation you need to know when objects pass away:

Ending game objects
Explicit ending via endObject()
Explicit ending via end object actuator
implicit ending when the parent gets ended
implicit ending when the scene ends (<-- I guess this is your situation)

Dealing with erroneous situations
When you know what object causes the problem, you should redesign your code. The basic mission is:
[INDENT]Ensure that ended objects get not referenced anymore[/INDENT]

There are several options:

A) when accessing an object check if it is still valid with KX_GameObject.invalid. But this is not much better than the zombie message. The design is still not good.


if gameObject.invalid:
  doNotAccessObject(gameObject)
else:
  accessObject(gameObject)

B) Always look for the latest object when you need it and you can’t be sure it is not ended. This means … you do a search at every Python call


gameObject = scene.objects["MyGameObject"]

Constantly performing a search is eating processing time.

C) When objects are removed, refresh all references. Unfortunately it means you need to cover all situations andyou need to know all references. Which is usually not very sufficient, if possible at all.


myRelevantObjects = []
myRelevantObjects = scene.objects["MyGameObject"]
...
myObject.endObject()
myRelevantObjects.remove(myObject]

Finally you need a mix of all of them.
E.g. refreshing a reference when the current one is not valid:


def getCachedObject(name):
  cache = getCache()
  object =cache .get(name)
  if not object or object.invalid:
     object = findObjectByName(name)
     cache[name] = object
  return object

def putObjectToCache(name, object):
   getCache()[name] = object

As said, the solution depends strongly on your situation. There is no general one. Otherwise the zombie message would not be needed.

Okay, well…

I started doing more extensive testing, and found out something interesting. Apparently, the enemy object is not causing the crashes. Its presence, existence, and operability make no difference to the crashing problem. Rather, the presence of a navigation mesh is causing the anomaly. Sorry for the false lead.

Tomorrow I plan to take a closer look at blender tutorials, documentation, and/or examples to make absolutely sure I’m setting up and using navigation meshes properly. In the meantime, has anyone ever had problems with navigation meshes causing crashes during scene changes?

As stated above, no objects are being ended. But I do know what is happening.

You advised in a previous thread of mine to split up the physical/visual/logic part of the enemy and the pathfinding into two unique objects, in order to settle my qualms with the steering actuator’s shortcomings. The results worked spectacularly, but I thought having two different objects connected by logic meant that I would have to have a parent-child relationship in order to spawn an enemy at runtime.

A child object cannot pathfind properly, so I set up the logic so that the pathfinding ‘Leader’ object would remove its parent at the game’s outset. That change in parentage seems to be messing with the logic, and resulting in the zombie object warning. Be aware that I’ve now devised a workaround, and will be attempting to build it soon.

I just fixed the zombie object warning, while retaining the features and flexibility of the former system. The enemy now spawns and defines its leader object at start up, and adjusts its properties to change its behavior. I also removed a problematic but unused import that was preventing the AI from working in the standalone file.

That still leaves the elephant in the corner, however, as I’m still getting crashing when any navigation mesh is in the scene, and I can’t figure out why. Attached is an updated file, with readme for clarity.

TGTEAGs_UploadB.blend (1.52 MB)

I did not discovered a crash, :(.

'm still getting crashing when any navigation mesh is in the scene, and I can’t figure out why. Attached is an updated file, with readme for clarity.

That is a bug in Blender.

A bug in Blender, as in, a bug in my copy or version of Blender, or a bug in Blender, as in, a known bug in every version of Blender to date? As I assume it’s the latter, I have to say it’s a shame.

While I can certainly ignore it for now, might there be any kind of ETA on a patch?

Crashes are always worth a bug report. The difficult thing is to create a small demonstration file that allows to reproduce the erroneous situation. This way the developer can
A) confirm it is there
B) investigate into the cause
C) prove they fixed it

Benoit Bolsee has fixed the bug in commit 8aa203a 08.08.2014.
You can try a actual build from the Blender build bot.
https://builder.blender.org/download/