Stage::getName(): illegal level error

[Samuel Flores]

Hi Guys,

Have you changed something about how CompoundSystem::realizeTopology() works? I realize that is actually implemented in System. I am getting the following error:

MMB: /home/samuelf/SimTK/include/simbody/SimTKcommon/internal/Stage.h:157: SimTK::String SimTK::Stage::getName() const: Assertion `!"Stage::getName(): illegal level"' failed.

This is just after I make a call to CompoundSystem::realizeTopology() . This particular call has been in my code for a long time so in that sense it is surprising that the updated simbody should cause a break here. I have been having some issues with system energies returning "inf" and the subsequent simulation crashing -- this happens stochastically even though I have no random numbers in my simulation. These two issues may or may not be related.

I much appreciate any help.

Thanks

Sam

[Michael Sherman]

Hi, Sam. I don't know of any change that would have affected this. The error message you posted indicates that a "Stage" value was garbage (not just uninitialized, because in that case it would have had the value "Empty"). That suggests trashed memory to me. This is the code that issued the error:

Code: Select all

    /** Return a printable name corresponding to the stage level currently
    stored in this Stage. **/
    String getName() const {
        switch (level) {
        case Empty:         return "Empty";    break;
        case Topology:      return "Topology"; break;
        case Model:         return "Model";    break;
        case Instance:      return "Instance"; break;
        case Time:          return "Time";     break;
        case Position:      return "Position"; break;
        case Velocity:      return "Velocity"; break;
        case Dynamics:      return "Dynamics"; break;
        case Acceleration:  return "Acceleration"; break;
        case Report:        return "Report";   break;
        case Infinity:      return "Infinity"; break;
        default: assert(!"Stage::getName(): illegal level");
        }
        return String("INVALID STAGE LEVEL ") + String(level);
    }

Also, the "assert()" in that code, and typically Stage::getName() itself, is only invoked during Debug builds. So you are running a Debug build and should be able easily to get a full stack trace which might help pinpoint the problem.

Regards, Sherm

[Samuel Flores]

Turns out if I checkout an earlier version of simbody (before this assert existed) I nonetheless get a crash, except without this nicer and more informative assert. This even happens when I roll back to an earlier version of MMB. Actually even old binaries that once worked now do not work. I guess the finger points to something about the OS which may have changed recently. This is a supercomputer so I am sure they are doing things all the time that I might not otherwise notice.

Sam

[Samuel Flores]

How is simbody supposed to find SFMT.h? I had to put an explicit flag in, which seems kludgy:

CMAKE_CXX_FLAGS -std=c++11 -lstdc++ -I /home/flores/github/simbody/SimTKcommon/Random/src/

I am also having some redefinition issues, which may be somehow related:


[ 13%] Building CXX object SimTKcommon/sharedTarget/CMakeFiles/SimTKcommon.dir/__/Polynomial/src/rpoly.cpp.o
Linking CXX shared library ../../libSimTKcommon.so
CMakeFiles/SimTKcommon.dir/__/Mechanics/src/CoordinateAxis.cpp.o:(.bss+0x20): multiple definition of `SimTK::XAxis'
CMakeFiles/SimTKcommon.dir/__/src/CoordinateAxis.cpp.o:(.bss+0x20): first defined here
CMakeFiles/SimTKcommon.dir/__/Mechanics/src/CoordinateAxis.cpp.o:(.bss+0x1c): multiple definition of `SimTK::YAxis'
CMakeFiles/SimTKcommon.dir/__/src/CoordinateAxis.cpp.o:(.bss+0x1c): first defined here
CMakeFiles/SimTKcommon.dir/__/Mechanics/src/CoordinateAxis.cpp.o:(.bss+0x18): multiple definition of `SimTK::ZAxis'
CMakeFiles/SimTKcommon.dir/__/src/CoordinateAxis.cpp.o:(.bss+0x18): first defined here

ElementFilter.cpp:(.text+0x0): multiple definition of `SimTK::operator<<(std::ostream&, SimTK::RowCol const&)'
CMakeFiles/SimTKcommon.dir/__/src/ElementFilter.cpp.o:ElementFilter.cpp:(.text+0x0): first defined here


Any advice is most welcome

Thanks

Sam

[Samuel Flores]

.. the latter is actually on a second machine. suspecting changes in the environment, I am trying to compile on another cluster that I haven't used in a while.

sam

[Michael Sherman]

Hi, Sam. I'm suspecting compiler problems on the machines you are using -- those multiple definitions and failure to find a header file are very suspicious! Can you find out the kind of compiler and its version number?

Sherm