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/ShowBase.py", line 1815, in updateManagers
self.physicsMgr.doPhysics(dt)
AssertionError: !child_vector.is_nan() at line 59 of panda/src/physics/linearForce.cxx
Traceback (most recent call last):
File "GameCore.py", line 1471, in <module>
gameFramework.run()
File "/usr/local/lib/python3.6/dist-packages/direct/showbase/ShowBase.py", line 3152, in run
self.taskMgr.run()
File "/usr/local/lib/python3.6/dist-packages/direct/task/Task.py", line 537, in run
self.step()
File "/usr/local/lib/python3.6/dist-packages/direct/task/Task.py", line 491, in step
self.mgr.poll()
File "/usr/local/lib/python3.6/dist-packages/direct/showbase/ShowBase.py", line 1815, in updateManagers
self.physicsMgr.doPhysics(dt)
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?
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?
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.
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?
[edit]
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.
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.
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…
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.)
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.
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.