Closed adamkewley closed 1 month ago
Private (research) model requested and received. I'll hold this in private storage as issue_773_source_model.osim
.
The model was sucessfully loaded with no crash or error in the following configurations:
So I cannot reproduce the error with the given model file - I'll ask him for more information.
One part of his bug was fixed in 16f46e7 but it wasn't tagged with an issue number because I noticed it in passing.
I have received a file that crashes from DKS. Details are:
_slave
joints.finalizeConnections
Tested against:
Version | Result |
---|---|
main |
Broke |
0.5.2 | Broke |
0.4.1 | Broke |
0.4.0 | Broke |
0.3.2 | Broke |
0.2.0 | Broke |
0.1.6 | Working |
0.1.0 | Working |
So there might be hint about how to fix it in the diff between 0.1.6 and 0,.2.0
The reason why 0.1.6 works is because it doesn't go through the step of re-finalizing connections:
It subsequently crashes if a connection-finalizing operation is performed later in the editing cycle (e.g. change the name, no crash; then change a joint, crash - but the crash is related to finalizing connections).
I created a simplified version of the model graph to visually inspect where exactly the cycle is in this particular model:
It looks like pectoral_girdle_b
is attached to ground via two "directions". I.e. sometimes it's the parent, sometimes it's the child, in a mobilizer relationship. This is accepted by SimTK, but creates a graph cycle, which leads to OpenSim generating slave
bodies, which leads to this particular bug.
3b24088 adds an even simpler bug reproduction, which is a file containing only two bodies and three joints.
The simplest possible failing version would be a single body and two joints, but that is co-incidently caught by https://github.com/opensim-org/opensim-core/issues/3299
Now that I have delved into the segfault debug trace, reproduced the bug in a way that's independent of mesh data, muscles, etc. I think it is safe to conclude that this particular bug is related to how OpenSim's sockets retain pointers for longer than needed.
What's happening here is:
slave
bodyslave
are createdslave
and creates a new slave
in a different memory location.slave
are stale--the original slave
has been deleted--segfault.So the "hollistic" solutions to this (in OpenSim) are:
slave
elements are proactively cleared of pointers before graph traversal - this requires a change in OpenSim because only OpenSim internally knows which components are "adopted", etc.Non-"hollistic" solutions include:
But that comes with its own baggage.
User reported that this problem appears to be fixed for their model, so closing this
Received in private email (search: "opensimcreator project Smith")
User reports that OSC is crashing whenever he loads his model file in it. And that the issue did not exist in v3.2 (assuming he means 0.3.2).