opensim-core icon indicating copy to clipboard operation
opensim-core copied to clipboard

Tests fail in debug mode on windows

Open aymanhab opened this issue 4 years ago • 5 comments

This seems related to the refactoring of the ComponentPath as shown in the stacktrace below > osimCommon_d.dll!anonymous namespace'::normalize(std::string path) Line 140 C++ osimCommon_d.dll!OpenSim::ComponentPath::ComponentPath(std::string path) Line 252 C++ osimCommon_d.dll!OpenSim::AbstractSocket::checkConnecteePathProperty() Line 281 C++ osimCommon_d.dll!OpenSim::Component::finalizeFromProperties() Line 216 C++ osimCommon_d.dll!OpenSim::Component::componentsFinalizeFromProperties() Line 288 C++ osimCommon_d.dll!OpenSim::Component::finalizeFromProperties() Line 233 C++ osimCommon_d.dll!OpenSim::Component::componentsFinalizeFromProperties() Line 288 C++ osimCommon_d.dll!OpenSim::Component::finalizeFromProperties() Line 233 C++ osimSimulation_d.dll!OpenSim::Model::Model() Line 86 C++ osimSimulation_d.dll!RegisterTypes_osimSimulation() Line 148 C++ osimSimulation_d.dll!osimSimulationInstantiator::registerDllClasses() Line 307 C++ osimSimulation_d.dll!osimSimulationInstantiator::osimSimulationInstantiator() Line 302 C++ osimSimulation_d.dll!dynamic initializer for 'instantiator''() Line 136 C++ This happens when path="", message "front() called on empty string"

aymanhab avatar Aug 25 '20 04:08 aymanhab

@adamkewley When you have a chance can you run tests on Windows in Debug mode? If not what's the expected behavior when normalize is fed an empty string? returning the empty string causes problems downstream. It's not clear what assumptions are made about ComponentPath now. Thank you.

aymanhab avatar Aug 26 '20 18:08 aymanhab

@aymanhab sure, I'll have a look. Can't be until next Monday though (holiday atm). I thought I emulated the behavior of empty strings to match the previous implementation. Is this specifically debug mode in Windows?

adamkewley avatar Aug 26 '20 19:08 adamkewley

Thanks @adamkewley Indeed this is only in Windows/Debug mode. STL libraries/classes on windows have extra checks in debug mode that are tripping at corner cases (e.g. "cannot seek string iterator after end"). Will try to work around these until you're back. Enjoy the holiday 🍺

aymanhab avatar Aug 26 '20 21:08 aymanhab

Yeah, it seems like the issue is that the code relies on str[str.size()] being legal. It should be legal in c++11 onwards because, after c++11, a basic_string<T> is defined to be a contiguous sequence of T, terminated by T{}. But str.front() might have an additional constraint in that it shouldn't be called on empty strings, despite str[0] == str[str.size()] being legal, and despite front being definined as equivalent to str[0].

I'm hoping it's just an overly cautious debug check by msvc, rather than the alg actually being incorrect and reading junk memory locations. A lot of the implementation relies on the presence of a nul senteniel.

On Wed, Aug 26, 2020, 11:35 PM Ayman Habib [email protected] wrote:

Thanks @adamkewley https://github.com/adamkewley Indeed this is only in Windows/Debug mode. STL libraries/classes on windows have extra checks in debug mode that are tripping at corner cases (e.g. "cannot seek string iterator after end"). Will try to work around these until you're back. Enjoy the holiday 🍺

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opensim-org/opensim-core/issues/2866#issuecomment-681136268, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEC5SR4QCZP6NMC6E75SHTSCV5ZNANCNFSM4QKGF2HQ .

adamkewley avatar Aug 27 '20 06:08 adamkewley

Related work in PR #2870 fixes some of the debug issues but the others need separate investigation.

Aggregating some of the notes from that PR, the known--still not fixed--issues I experienced even after #2870 's fixes are (MSVC2019, debug build of b155f219):

1>The following tests FAILED:
1>	 21 - testContactGeometry (Failed)
1>	 47 - testVisualization (Failed)
1>	 48 - exampleHopperDevice (Failed)
1>	 49 - exampleHopperDeviceAnswers (Failed)
1>	 92 - testOpenSense (Timeout)
1>Errors while running CTest

With error messages like:

1>47/93 Test #47: testVisualization ............................***Failed    0.57 sec
...
1>[warning] Model 'model' has subcomponents with duplicate name 'ground_offset_frame'. The duplicate is being renamed to 'ground_offset_frame_0'.
1>[warning] Model 'model' has subcomponents with duplicate name 'ground_offset_frame'. The duplicate is being renamed to 'ground_offset_frame_1'.
1>Failed to connect Socket 'parent' of type PhysicalFrame (details: Connectee for Socket 'parent' of type PhysicalFrame in PhysicalOffsetFrame at /ground_offset_frame is unspecified. If this model was built programmatically, perhaps finalizeConnections() was not called before printing.
1>	Thrown at Component.h:3344 in finalizeConnection().).
1>	In Object 'ground_offset_frame' of type PhysicalOffsetFrame.
1>	Thrown at Component.cpp:313 in finalizeConnections().


1>      Start 49: exampleHopperDeviceAnswers
1>49/93 Test #48: exampleHopperDevice ..........................***Failed    1.68 sec
1>Hopper Example Failed to run due to the following Exception: Component 'Dennis' of type Model is the root but has no subcomponents listed.
1>Verify that finalizeFromProperties() was called on this Component to identify its subcomponents.
1>	Thrown at Component.cpp:1751 in initComponentTreeTraversal().


1>      Start 50: testComponents
1>50/93 Test #49: exampleHopperDeviceAnswers ...................***Failed    1.75 sec
1>Hopper Example Failed to run due to the following Exception: Component 'Dennis' of type Model is the root but has no subcomponents listed.
1>Verify that finalizeFromProperties() was called on this Component to identify its subcomponents.
1>	Thrown at Component.cpp:1751 in initComponentTreeTraversal().
1>

1>82/93 Test #21: testContactGeometry ..........................***Failed  1243.67 sec
...
1>Exception:
1>  Failed to connect Socket 'child_frame' of type PhysicalFrame (details:
1>  Connectee for Socket 'child_frame' of type PhysicalFrame in PinJoint at
1>  /jointset/hinge is unspecified. If this model was built programmatically,
1>  perhaps finalizeConnections() was not called before printing.
1>  Thrown at Component.h:3344 in finalizeConnection().).
1>  In Object 'hinge' of type PinJoint.
1>  Thrown at Component.cpp:313 in finalizeConnections().

1>93/93 Test #92: testOpenSense ................................***Timeout 1500.02 sec
1>[info] Loaded model Subject07 from file subject07.osim
...

Those tests also seem to fail on a 4.1 checkout of OpenSim, which indicates that they may have been failing for a while. Only I have checked this, so it might be an idea for someone else to confirm they're seeing these failures when building with MSVC2019 + Debug.

I have not bisected the failures to figure out which commit introduced them, but it would not surprise me if they have been there since the tests were initially implemented. The reason I think this is because there are many TODO comments in the model-building part of the code that mention things like "should probably do this and that when building this model" and the breakages seem to be related to things being missing from the model. I'm unsure, though, and this requires further investigation.

The #2870 PR contains a more extensive dive into these errors as part of ensuring that they were not introduced by the new ComponentPath changes.

adamkewley avatar Sep 02 '20 10:09 adamkewley