Physics Crash: Force-related vector holding "not a number"

Every so often–very seldom, in fact–and usually when something else is going wrong (such as extraneous circumstances causing an extremely low frame-rate) a crash occurs in Bullet’s logic.

I only have the most recent such crash to hand, I think, and it’s been long enough since the last one that I don’t know whether it was the same.

That said, here is that most-recent crash:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/direct/showbase/", line 1815, in updateManagers
AssertionError: !child_vector.is_nan() at line 59 of panda/src/physics/linearForce.cxx
Traceback (most recent call last):
  File "", line 1471, in <module>
  File "/usr/local/lib/python3.6/dist-packages/direct/showbase/", line 3152, in run
  File "/usr/local/lib/python3.6/dist-packages/direct/task/", line 537, in run
  File "/usr/local/lib/python3.6/dist-packages/direct/task/", line 491, in step
  File "/usr/local/lib/python3.6/dist-packages/direct/showbase/", line 1815, in updateManagers
AssertionError: !child_vector.is_nan() at line 59 of panda/src/physics/linearForce.cxx

As you can see, the issue seems to occur in “doPhysics”, and seems to result from some vector being “not a number”.

Does anyone here know what might be causing this, and whether it’s something to be concerned about? And if it is worth worrying about, does anyone have any suggestion as to how I might reproduce the issue somewhat reliably, so that I can test any potential solutions that I might attempt?

You are talking about a bullet, however the file with the error refers to the source of the panda. To be exact on panda physics.

If so, then that would be very odd: I’m pretty confident that I’m not using Panda’s built-in physics in this project (aside from activating it for the sake of having particle effects).

That said, are we confident that it is indeed referring to Panda’s built-in physics, and not indirectly controlling the Bullet implementation?

I am not 100% sure.

I found information that the type “bool” is sometimes returned.

Hmmm… “bool” is what I’d expect that function to return, I think: it’s checking to see whether the value is “not a number”, and returning either “true” or “false” as appropriate, presumably.

However, I think it’s still the 3D panda code. It all fits together.

Possibly–although I’ll note that there seems to be a gap in the stack trace: it goes from “self.physicsMgr.doPhysics(dt)” to “get_vector” (by the looks of it), without a trace of the path between the two. Perhaps that’s because it’s accessing a third-party library, like Bullet?

One possible source of such a call in my code, come to think of it, might be particle-forces.

If so, then such an error would seem to imply a bug in Panda, I think.

Obviously, physicsMgr belongs to the panda.

Indeed, but a crash in Panda’s code could always come from bad input on my side. In this case, however, I imagine that it’s more likely a Panda issue–if it is as it seems.

I think that this error can be repeated if you pass the type “bool”. Perhaps where in your logic there is such a code.

Hmm, I doubt that’s the source–the only calls to a “doPhysics” method that I’m making myself are to Bullet’s “doPhysics” method, and those should be getting either hard-coded floats or the result of the global clock’s “getDt” method…

Although not, this does not cause this error.

from direct.showbase.ShowBase import ShowBase

class MyApp(ShowBase):

    def __init__(self):
app = MyApp()

Obviously this is a method: LinearForce which received the type “bool” I think I’ll check later.

I’m not sure that it’s receiving a bool, necessarily; it could be receiving some other invalid value. (In fact, looking at the specification, I’m not sure that “is_nan” would return “true” given a bool.)

I think you should send a request to GitHub. This is a bug in the effects engine. Also rename the post, maybe someone is faced with this.

Hmm… Fair enough. I’m still not convinced that it’s not Bullet-related–but in case it isn’t, I’ll make the thread-title more general by removing the reference to Bullet, I think.

And indeed, I’ll file a GitHub report, I intend.

Done; here is a link to it:

Take a look here:

By the way, your showbase file has plus one line.

Hmm… Looks like you’re right–tracing where that “physicsMgr” is assigned does seem to indicate that it’s set when “enableParticles” is called. Fair enough, then; presuming that no further code changes it again at some point (I haven’t looked), it does seem that I stand corrected.

(Also, note the link to the GitHub issue in my previous post, in case you’re interested in following it.)

Sorry, I just noticed this.

I’m using a dev build, I believe, so that it incorporates a minor change to particle timing capabilities–that might be the reason that my “ShowBase” file has an extra line.